It seems the vanilla-sources ebuild doesn't obei "-symlink" in USE. The /usr/src/linux symlink is (re-)created at every update. # emerge -pv vanilla-sources These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-kernel/vanilla-sources-2.6.16 USE="doc -build -symlink" 0 kB # epm -qi vanilla-sources Name : vanilla-sources Version : 2.6.16 Release : Slot: 2.6.16 Install date: Mon Mar 27 08:32:36 2006 Build Host: louisa Group : sys-kernel License: GPL-2 Size : 223206412 Packager : brix URL : http://www.kernel.org Summary : Full sources for the Linux kernel # ll /usr/src/linux lrwxrwxrwx 1 root root 12 Mar 27 08:33 /usr/src/linux -> linux-2.6.16/
did /usr/src/linux exist previously? it creates the symlink regardless if it doesnt exist.
(In reply to comment #1) > did /usr/src/linux exist previously? No. > it creates the symlink regardless if it doesnt exist. Yes, that's what the bugreport is about.
Ah, OK now I see where you are coming from. if /usr/src/linux doesnt exist, then we should always create this symlink to satisfy other ebuilds in the tree which use kernel sources as a base for kernel information. Perhaps -symlink is a little misleading, considering it still creates the symlink, but this really is desired behaviour. If /usr/src/linux were to already exist, pointing to anything you liek really, then it wouldn't re-write /usr/src/linux. Does this cause any kind of issues outside of the misleading impression that the useflag gives (when not used)?
(In reply to comment #3) > Ah, OK now I see where you are coming from. > if /usr/src/linux doesnt exist, then we should always create this symlink to > satisfy other ebuilds in the tree which use kernel sources as a base for kernel > information. OK. > Perhaps -symlink is a little misleading, considering it still creates the > symlink, but this really is desired behaviour. If /usr/src/linux were to > already exist, pointing to anything you liek really, then it wouldn't re-write > /usr/src/linux. Didn't know that. > Does this cause any kind of issues outside of the misleading impression that > the useflag gives (when not used)? No. Just had that LKML post of Linus about the symlink issue in mind.
(In reply to comment #4) > No. Just had that LKML post of Linus about the symlink issue in mind. Do you have an URL for that post, please?
If it's the old one that gets referenced a lot, then yes, Linus is right, but that doesn't apply to Gentoo. We have separate kernel headers in /usr/include/ and we recommend rebuilding glibc every time the /usr/include kernel headers change. This was not the case for most distros back then, and may even still be true today.
(In reply to comment #5) > (In reply to comment #4) > > No. Just had that LKML post of Linus about the symlink issue in mind. > > Do you have an URL for that post, please? http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html
this is the primary reason why os's ship linux/os-headers. basically, userland *should* use libc, and libc *should* extract the linux kernel headers. Sometimes however things do need the kernel headers directly, and as such should look in /usr/include[/linux] since anything compiling against /usr/src/linux is broken. (I could point people to mplayer here). The reason we use a /usr/src/linux symlink isnt because of compile-time dependancies for things in userland. Its for a point to reference when we need to obtain kernel information, or build kernel modules (which genuinely need the kernel source). Many people might say "Why not use `uname -r`?" but the answer here is simple. We dont tie you in to the current running kernel. We allow for cross-compile, compiling for a source your about to boot, etc etc.
assuming everyone is happy, and my waffling made a small degree of sense, I'll close this as wontfix. However, I encourage your active bug reporting and please continue to do so :) I like people being observant - it keeps us on our toes.
(In reply to comment #8) > basically, userland *should* use libc, and libc *should* extract the linux > kernel headers. s/extract/abstract/
