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 attachment 102054 [details, diff] 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. ***
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 ***
