Bugzilla Bug 154495

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.

Any suggestions for how that might happen without breaking source build users?

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.

Please, stop messing with severity and components of this bug.

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

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).

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.

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?

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.

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.

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?

(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!

Created an attachment (id=102054) [details]
add FEATURES="bindist" to support precompiled kernel modules installation

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.

Your linux-info changes will affect a much larger range of packages than just
kernel modules. Those changes require more consideration, I think.

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! ;)

A features flag for what exactly?

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.

Portage developers: any opinions on the problems and solutions outlined here?

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.

Bug 174380 tracks EAPI-1 enhancements and something like a new
pkg_setup_binary() phase might be a good candidate for that.

*** Bug 185914 has been marked as a duplicate of this bug. ***

*** Bug 188769 has been marked as a duplicate of this bug. ***

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...

*** Bug 195601 has been marked as a duplicate of this bug. ***

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}
}

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.

*** Bug 265520 has been marked as a duplicate of this bug. ***