I just had a problem with the headers of linux-headers being incompatible with the ones of the kernel I compiled. Well no big deal to fix this, but you should consider solving this problem more fundamentally: I'll propose a system here which SuSE is using: -you either install kernel sources OR the linux-headers package and the system should pick the headers you need like this: -The entries in /usr/include/linux and /usr/include/asm are just symlinks to /usr/src/linux/include/linux and /usr/src/linux/include/asm -linux-headers is installed into /usr/src/linux-headers-xx -You choose the headers you want to use by creating a symlink in /usr/src/linux, the package which has been installed last should set this link. Examples: ln -s /usr/src/linux-2.4.19-gentoo-r10 /usr/src/linux ln -s /usr/src/linux-2.4.19-headers /usr/src/linux ... Greetings, Matze
AN interesting point, but then if a user had their headers linked to /usr/src/linux and installed a kernel modules package this would break. However having our linux-headers package install itself into /usr/src/linux-headers-version with a symlink to /usr/src/linux-headers which could be changed before the remerging of glibc to point to /usr/src/blah-sources-blah and would make this feasible and not ugly at all, I'll be pondering this as an alternate solution to some of the others I've been considering.
*** Bug 10753 has been marked as a duplicate of this bug. ***
*** Bug 16096 has been marked as a duplicate of this bug. ***
This *is* causing reduced functionality in the wireless tools package as things stand as it is an OLD version of the wireless extensions in /usr/include/linux I will make a suggestion to the wireless_tools maintainer to build with the includes from the current /usr/src/linux in the same way that pcmcia-cs does but I do think that this long standing issue should be properly resolved
I agree that something must be done here. Things to note: - some people (like me on my laptop) have only limited diskspace, and they might remove the linux sources package. The headers would then still be installed, through linux-headers. So using a symlink to the kernel sources doesn't work. - linux-headers installs vanilla headers. So any patches that are applied on your kernel are not taken into account. I think that linux-headers should be a virtual ebuild, along the lines of the perl ebuilds. It should figure out the kernel version in /usr/include/linux, copy the include files to /usr/include/linux-$version and /usr/include/asm-$version, and make the symlinks /usr/include/{linux,asm} to point at them. Possibly, it could be an ebuild that gets created by installing one of the kernel source packages, and which then gets emerged automatically.
I don't like this suggestion: -You can simply install kernel headers package in /usr/src/linux-headers-2.4.20 or something and do the same symlinks. -The proposed solution needs more copying and symlinking around and is therefore more complex than needed. In my suggestion you'd only had to change the symlink in /usr/src/linux. I can't see any real problems with this approach and would like to see this finally changed.
You misunderstand the issue. The kernel headers in /usr/include should be the kernel headers glibc was compiled against ...
I will refrase the issue: 1) The kernel headers in /usr/include should be the kernel headers glibc was compiled against. 2) Anything that absolutely need the current kernel's headers should: a) Call 'check_KV' to see that /usr/src/linux is valid b) Configure the package to include the headers in /usr/src/linux/include Most things that will fall under 2) will be kernel modules (wireless tools package?), etc. The logic behind 1) is that glibc, and thus any calls is configured according to the state of /usr/include/{asm,linux}, and thus anything that use kernel headers with glibc calls should also use /usr/include/{asm,linux}, else hairy problems might arise. Thus is obviously not true for things like kernel modules and iptables (also very kernel specific) that greatly depends on the state of the current kernel. For 2), it is mostly based on the Gentoo 'policy' as I had it last.
Thus to get back to comment #4, if the wireless package are as kernel specific as iptables for instance, then it should rather be its package that needs to be fixed to do the proper 'check_KV' call, and include headers in /usr/src/linux/include .....
Ah, I didn't know that switching kernel headers is problematic without recompiling glibc. In this case you should enforce your policy here. The glibc build should simply copy the headers to /usr/include/linux and /usr/include/asm after building. However this doesn't solve the problem that many kernel packages which can be found elsewhere use /usr/include/linux (like my wlan drivers - I know I'm too lazy to write ebuilds...). If there's no way to switch headers after compiling glibc, then we should at least output a message to the user after emerging kernel sources, that he should recompile glibc! That will at least limit confusion.
Check comment #9 ... if it needs kernel specific headers, tweak the configure/Makefile of the package to use the ones in /usr/src/linux/include ...
I think I can close this - this has been discussed many times over and I think Martin's explained the situation in comment #8 - currently, /usr/include/linux is only used for low-level libraries such as filesystem utilities and glibc. That's pretty much it. Note that glibc does not have to be updated if you change your headers * unless * you want to gain some more functionality from your new headers. Also, it is much better to use /usr/src/... headers for a variety of reasons: mainly, the one that drivers usually require the running kernel, and that most ebuilds already utilize that system - and things like having 2.4 headers on a 2.6 kernel are solved by using your kernel headers for ebuilds which need them.
