Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 154495 - [Future EAPI] Provide ebuilds a way to differentiate between ebuild and binpkg in pkg_setup()
Summary: [Future EAPI] Provide ebuilds a way to differentiate between ebuild and binp...
Status: RESOLVED DUPLICATE of bug 347351
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: High minor (vote)
Assignee: PMS/EAPI
URL:
Whiteboard:
Keywords:
: 185914 188769 195601 265520 (view as bug list)
Depends on:
Blocks: 206024 286292
  Show dependency tree
 
Reported: 2006-11-08 11:29 UTC by Fabio Erculiani
Modified: 2011-04-10 22:30 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
add FEATURES="bindist" to support precompiled kernel modules installation (binary-kernel-modules-support.patch,1.95 KB, patch)
2006-11-16 03:35 UTC, Fabio Erculiani
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Fabio Erculiani 2006-11-08 11:29:49 UTC
Precompiled packages shouldn't depent on installed (or even not) kernel sources.
Just try to:

- quickpkg <kernel-sources-dependent-package> (like nvidia-drivers but even pcmciautils)
- mv /usr/src /usr/src_tmp
- emerge -K <kernel-sources-dependent-package>

We have two broken points in linux kernel related eclasses.
The first is that the ebuilds check for an installed kernel source tree.
The second is that they look at its version.

So, the proposal is to let emerge -K work and bypass kernel sources check.
Comment 1 Daniel Drake (RETIRED) gentoo-dev 2006-11-08 11:54:47 UTC
Any suggestions for how that might happen without breaking source build users?
Comment 2 Fabio Erculiani 2006-11-08 12:29:46 UTC
no, not for now, but if you want I can look into that.
anyway, some time ago it worked flawlessly (I mean, doing that worked) but now it does not.
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2006-11-08 12:34:52 UTC
Please, stop messing with severity and components of this bug.
Comment 4 Fabio Erculiani 2006-11-08 12:43:06 UTC
ok Jakub, but I don't have much time to scroll all the list.
And I don't think that's a minor problem, well... it is "normal" at least.

I am finding a lot of fresh portage/eclasses "bugs"/odd behaviors in these days :P Just doing a mass submitting
Comment 5 Jakub Moc (RETIRED) gentoo-dev 2006-11-08 12:51:57 UTC
Err, see - this is pretty simple: pkg_* functions are executed for both binpkgs and ebuilds, there's no way around it. So unless you have a suggestion where to move or how to change those checks without breaking compiling from source, this bug will end up as CANTFIX (and no, src_{unpack,compile} is not a viable option for them).

Comment 6 Daniel Drake (RETIRED) gentoo-dev 2006-11-08 12:59:05 UTC
Please go ahead, I don't have any immediate ideas and these eclasses do not really have developers or maintainers right now.

(In reply to comment #2)
> anyway, some time ago it worked flawlessly (I mean, doing that worked) but now
> it does not.

I think that in the times you are referring to, things were far from flawless for from-source users, which is really our focus here. While they will work when done carefully, external kernel modules as binary packages involves a small degree of insanity: many of them are illegal to distribute, they will not consider the running kernel version, will have to be manually rebuilt and pushed out for every single kernel version change, etc.
Comment 7 Fabio Erculiani 2006-11-08 15:01:17 UTC
well, could I try to write a fix for all that stuff Daniel?

Because it's not only the non-GPL drivers that do not work, it's all kernel-dependent modules.

*  net-wireless/rt61
      Latest version available: 1.1.0_beta1
      Latest version installed: 1.1.0_beta1
      Size of files: 334 kB
      Homepage:      http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page
      Description:   Driver for the RaLink RT61 wireless chipsets
      License:       GPL-2

this for example, is released under the GPLv2.
There are ways to distribute nvidia drivers in a legal way, just link those against the GPL part at runtime. So, you workaround the "shipping issue".

Anyway, I think that quickpkg and emerge -K are gentoo apps, not third party. that's why I don't like the fact that you say "we support only source compiled packages", because, IMO, if you have an officially documented feature, you should continue to support it. :)

And if we would use FEATURES="binhost" for this matter?
Comment 8 Daniel Drake (RETIRED) gentoo-dev 2006-11-08 16:53:03 UTC
If you could fix all the technical problems with binary packaging that would be grand. I have archived a write-up on a few more reasons why binaries don't fit into Gentoo very well here: http://dev.gentoo.org/~dsd/misc/binaries.html

Yes, this is something Gentoo aims to support, but does not support very well right now. This is a community project which has to yet to reach perfection, additional development resources are always needed and appreciated.
Comment 9 Daniel Drake (RETIRED) gentoo-dev 2006-11-08 16:55:40 UTC
Also, I'm pretty sure it's not possible to release a binpkg of the nvidia drivers without it having been linked with the kernel at that stage, but if I'm wrong I'd really appreciate an explanation. I'm having to deal with this at work right now.
Comment 10 Fabio Erculiani 2006-11-09 00:14:29 UTC
I don't know if it's legally possible but either NVIDIA and ATI will never bother you. The people that would complain are kernel devs. And as I said Daniel, the solution is quite easy. The problem is that you cannot ship nvidia.ko, this means that you cannot link nvidia.mod.o and nvidia.o and ship the result (nvidia.ko). But the solution is easy, just link them at runtime. So you won't never have the final binary blob in your distributions.

Last thing Daniel, so could I try to work out the kernel-dependent modules?
Comment 11 Daniel Drake (RETIRED) gentoo-dev 2006-11-09 05:17:16 UTC
(In reply to comment #10)
> I don't know if it's legally possible but either NVIDIA and ATI will never
> bother you. The people that would complain are kernel devs.

That's because the copyrights you infringe upon belong to the kernel developers, not nvidia.

> And as I said
> Daniel, the solution is quite easy. The problem is that you cannot ship
> nvidia.ko, this means that you cannot link nvidia.mod.o and nvidia.o and ship
> the result (nvidia.ko). But the solution is easy, just link them at runtime. So
> you won't never have the final binary blob in your distributions.

OK - so how can I produce a nvidia-drivers binpkg which does as you describe?

> Last thing Daniel, so could I try to work out the kernel-dependent modules?

Nobody is stopping anyone post solutions to bugs :)
Please go ahead and send us patches!
Comment 12 Fabio Erculiani 2006-11-16 03:35:46 UTC
Created attachment 102054 [details, diff]
add FEATURES="bindist" to support precompiled kernel modules installation
Comment 13 Fabio Erculiani 2006-11-16 03:38:04 UTC
This implementation uses FEATURES="bindist" but you could use what you think would fit better.

test:

quickpkg pcmciautils (or even rt61)
mv /usr/src /usr/src2
FEATURES="bindist" emerge -K --nodeps pcmciautils

it works here. I used a less invasive way to work out this issue.
Comment 14 Daniel Drake (RETIRED) gentoo-dev 2006-11-18 09:57:40 UTC
Your linux-info changes will affect a much larger range of packages than just kernel modules. Those changes require more consideration, I think.
Comment 15 Fabio Erculiani 2006-11-19 23:37:10 UTC
yes, you are right, I'd create a FEATURES flag for that.
It should be nice to have this problem fixed without creating a faked KERNELDIR structure though.

binpkgs are part of Gentoo, so, IMHO you should consider to fix it, in any possible way, I don't care :). I'm here to help, if you want! ;)
Comment 16 Daniel Drake (RETIRED) gentoo-dev 2006-11-20 05:23:31 UTC
A features flag for what exactly?
Comment 17 Fabio Erculiani 2006-11-23 00:23:02 UTC
uhm... it could be something like "no-kernel-check" ?
FEATURES="no-kernel-check" to disable the kernel detection and force the packages installation.

If there's something I could do, I'd like to help.
Comment 18 Daniel Drake (RETIRED) gentoo-dev 2006-12-21 19:15:57 UTC
Portage developers: any opinions on the problems and solutions outlined here?
Comment 19 Zac Medico gentoo-dev 2006-12-21 20:04:55 UTC
There is an EMERGE_FROM environment variable that emerge exports to the ebuild environment.  For binary packages it's value is "binary" for ebuilds it's value is "ebuild".  That's the only thing I'm aware of that will give you the necessary information and it's been around for a long time (apparently nothing in the tree uses it though).

For a more long term solution, we could consider adding a new phase to the EAPI, such as pkg_setup_binary(), that the package manager would call instead of pkg_setup() when a binary package is being installed.
Comment 20 Zac Medico gentoo-dev 2007-05-09 20:39:00 UTC
Bug 174380 tracks EAPI-1 enhancements and something like a new pkg_setup_binary() phase might be a good candidate for that.
Comment 21 Jakub Moc (RETIRED) gentoo-dev 2007-07-19 21:14:02 UTC
*** Bug 185914 has been marked as a duplicate of this bug. ***
Comment 22 Jakub Moc (RETIRED) gentoo-dev 2007-08-14 06:36:11 UTC
*** Bug 188769 has been marked as a duplicate of this bug. ***
Comment 23 Paul B. Henson 2007-08-15 01:22:35 UTC
Just to provide a use case for this feature, we have at least a couple of dozen Gentoo systems deployed providing various services, and to avoid wasted cycles we have a central server that compiles all of the packages which are then installed as binaries on the various other systems. We don't really want to have to have kernel sources installed on a bunch of clients that don't need them (that would violate the Gentoo philosophy of minimalism which initially attracted us to it).

For now, we are actually editing the binary .tbz2 file and updating the embedded ebuild within to comment out the code that checks for the kernel version so it will successfully install 8-/. Hopefully you guys will put together something saner to allow this functionality.

Thanks...
Comment 24 Jakub Moc (RETIRED) gentoo-dev 2007-10-12 09:52:25 UTC
*** Bug 195601 has been marked as a duplicate of this bug. ***
Comment 25 Zac Medico gentoo-dev 2008-01-11 03:14:55 UTC
One possible solution to this bug (and bug #139798) might be to move stuff from pkg_setup to the beginning of src_unpack. For example:

pkg_setup() {
  # stuff for both binary packages
  # and source packages here
}

src_unpack() {
  # stuff just for build time
  linux-mod_pkg_setup
  unpack ${A}
}
Comment 26 Zac Medico gentoo-dev 2008-02-16 21:03:54 UTC
Now that bug 56408 is fixed in the latest stable portage (2.1.4.4), it's possible for ebuilds set their own environment variables to deduce that the pkg_setup() function has been run previously. That should allow the pkg_setup() behavior to be altered so that it works correctly with binary packages.
Comment 27 Lars Wendler (Polynomial-C) gentoo-dev 2009-04-10 09:03:04 UTC
*** Bug 265520 has been marked as a duplicate of this bug. ***
Comment 28 Ulrich Müller gentoo-dev 2011-04-10 22:30:16 UTC
I think that this is covered by the MERGE_TYPE variable in EAPI 4.

*** This bug has been marked as a duplicate of bug 347351 ***