linux-info eclass should depend on having virtual/linux-sources installed. that is, inheriting linux-info should pull in kernel sources.
Fixed in linux-info.eclass (revision 1.39) and linux-mod.eclass (revision 1.58). Thank you for reporting this.
(In reply to comment #0) > linux-info eclass should depend on having virtual/linux-sources > installed. that is, inheriting linux-info should pull in kernel > sources. Why? My system has gotten along fine without virtual/linux-sources for the entire time I have been using Gentoo (nearly 2 years now). Suddenly, Gentoo seems to think virtual/linux-sources is needed to build x11-base/xorg-x11. It was never needed before. Why is virtual/os-headers not enough? What feature of linux-info.eclass needs virtual/linux-sources and can not work with just virtual/os-headers?
(In reply to comment #2) > What feature of linux-info.eclass needs virtual/linux-sources and can > not work with just virtual/os-headers? linux-info.eclass provides information about the kernel sources found in $KERNEL_DIR, it has nothing to do with virtual/os-headers. Pretty much all of the functionality found in linux-info.eclass depends on a kernel source being available.
xorg-x11 uses linux-info::kernel_is() which is a function for checking the kernel version found in $KERNEL_DIR ...
I second comment #2. My reasons are about gnupg which already had a bug open at bug 113474. So, can we work something out to *not* require the kernel sources unless absolutely necessary? Don't forget that there are valid setups where the running kernel is not necessarily located at /usr/src/linux. Or at least provide a mock-sources package that would install the bare minimum of files requird by linux-info. Makefile, .config and what else? I'd still hate it, but it would be bareable.
anything using linux-info/linux-mod (especially the latter) kind of has a pre-requisite of a kernel source tree. This has been spoke about to fall back on, lets say uname -r, but there is no way to work out which part of the version string is EXTRA,LOCAL etc. Anyways, this (although a good point) was always going to be problematic for several reasons. Namely, its against policy to assume the current running kernel. It doesnt provide granularity. It's not capable of checking kernel config prerequisites. etc. also: "Don't forget that there are valid setups where the running kernel is not necessarily located at /usr/src/linux." Thats why you have the possibility to over-ride that with KERNEL_DIR, and also if you really want to, KBUILD_OUTPUT
(In reply to comment #3) > (In reply to comment #2) > > What feature of linux-info.eclass needs virtual/linux-sources and can > > not work with just virtual/os-headers? > > linux-info.eclass provides information about the kernel sources found in > $KERNEL_DIR, it has nothing to do with virtual/os-headers. > > Pretty much all of the functionality found in linux-info.eclass depends on a > kernel source being available. What _information_ does it need? I have just done an "emerge world" after the change that "fixed" this bug and discovered that the package sys-kernel/gentoo-sources-2.6.15-r5 takes 282,263,552 bytes of disk space once installed. This filled up my hard disk and caused lots of things to start failing, so I had to immediately take emergency action and unmerge the package. Does linux-info.eclass really need 282,263,552 bytes of information to do its job? Obviously all the packages I am using don't need this information because my system has worked perfectly for years without it. Can you please undo this? Or change all the other packages in portage that don't really need this information (which is clearly most of them) to stop using linux-info.eclass? (In reply to comment #4) > xorg-x11 uses linux-info::kernel_is() which is a function for checking the > kernel version found in $KERNEL_DIR ... Why can't it just use "uname"? I would like to point out that I am not even running a kernel compiled by portage as I am using coLinux which needs a special kernel which actually lives on my Windows file system and doesn't exist in my Linux file system. So this approach can not possibly be obtaining useful information. I imagine I am not alone in this situation. I would rather not have to open a separate bug report on the problems caused by this "fix".
*** Bug 122250 has been marked as a duplicate of this bug. ***
*** Bug 122783 has been marked as a duplicate of this bug. ***
Reopen, see Bug 122783, Comment #5 for a possible solution.
re-closing this bug. In response to the question regarding the requirement of kernel sources... Basically, linux-info uses a lot of checks against kernel-source files to determine target kernel-version, Makefile specifics, CONFIG_* specifics etc. the 200m package is simply that big, because thats the size of a decompressed kernel source. There is a get_running_version function which uses uname -r but it is heavily discouraged except in specific cases because of the policy we use when determining what kernel version we are building against. You can add kernel virtuals etc to /etc/portage/package.provided without any issues to satisfy this dependancy requirement, and pass KERNEL_DIR to point to sources. I will be reviewing the logic of a couple of tests (kernel_is generally speaking) to better accomodate Gentoo/ALT but there will be little changes made outside of this. An example of such has been a conditional test for kernel_linux on the linux-sources depend, but there are a few small niggles with non-linux kernels and linux-info. Of course... its very questionable whether it should be using linux-info anyways and there will be a restructure once elibs are widely adopted to overcome this problem and provide much cleaner cross-kernel support. If you feel I am missing some technical issues, please comment on the bug and re-open, but for the time being I am closing as WONTFIX. Wranglers, please feel free to continue assigning dupes to this but removing dependancies from the eclass re: sources isnt going to happen when the vast majority of functions require information from source-tree files.
*** Bug 141188 has been marked as a duplicate of this bug. ***
*** Bug 198141 has been marked as a duplicate of this bug. ***
*** Bug 202717 has been marked as a duplicate of this bug. ***
