/usr/src/linux is almost invariably a symlink. It is also a symlink that many system administrators set *themselves*, and having a package change it seems poor form. I know of no other distro that tries to change it if it exists. I understand that there is a problem where, should the ordering of package installation and removal be appropriate, the /usr/src/linux symlink could end up dangling. However, a simple error message at portage startup should be enough incentive for the system administrator to *fix* the problem by his or her self. Additionally, as a separate issue, why does the kernel postinst do a 'make mrproper' if one has already been on in the src_unpack? Finally, why does the postinst do a make dep? I strongly oppose changing in *any* way the /usr/src/linux symlink. This is something that is very individual to system administrators.
The assumption is that if you are merging a new kernel source tree, you plan to use it. I'll think about it. No one has complained yet, but I see your point.
It is an interesting debate. One should probably pin a kernel version to keep the current one installed. This makes more sense, atleast for me.
That's all I ask! Thanks
Well, pinning a version wouldn't work for me, and it wouldn't work for many people, because lots of people don't use the packages directly. I really dig the idea of having 1 or more kernel sources in /usr/src, but I strongly feel that the /usr/src/linux symlink should be completely *hands off* (unless it doesn't exist at all) for the package system. The reason why is that many sys admins set that link themselves to one of many locations, any of which might not (and probably aren't) controlled by the package system. /home/user/kernels/my-favorite-*custom*-kernel/ is a common one.
My vote is to disable mangling the symlink, letting the sys admin deal with it manually.
I like that that /usr/src/linux is updated when I emerge a kernel. I see no technical reason *not* to update that symlink. While it is an inconvience for you to have to update it back to whatever you want if you emerge a new kernel package it is an inconvience for the user that use the kernel they just emerged. Which is the more common case? I don't have hard data but I think the latter. One reason I find that is not quite techinical but more valid than opinion that supports updating the symlink is so I can do things like: `emerege xfs-sources alsa-driver` . The alsa driver package uses that symlink to determine which kernel to compile against. I personally enjoy the convience of not having to remember to `emerge alsa-driver` as a later step. I also think auto updating the symlink more accuratly refects the expected behavior of emerging some kernel sources and alsa-drivers at once. I discussed this with some coworkers and while we didn't come to an agreement between us we all agreed that the issue was a personal preference and not a techinical one. Since people's opinions will differ I think you should do whichever would create the least work for most people. I think the people who find one kernel and stick with it are more common than those that go through kernels as fast as they are released.
I don't know if it is my system or not (probably is) but I have had a few "unresolved symbol in module foo" errors after booting a freshly built kernel that had /usr/src/linux pointing to it. Rebooting to the previous known good kernel, changing the symlink to point to the source for that known good kernel and rebuilding the new kernel fixed the problem for me. I currently have a this in local.start : ln -s /usr/src/linux-`uname -r` /usr/src/linux To make sure the sources of the running kernel are the ones linked to by /usr/src/linux. Given that Gentoo is not targeted at linux newbies my vote is to leave the symlink as it is and maybe add some checks during unmerge to inform the user that they will need to ensure that /usr/src/linux points to a valid kernel source tree.
Hmmm ... that last bit was a bit ambiguous. It should say... My vote is for the ebuilds to NOT touch the symlink and let it be set by the user.
I think that requiring the user to update the symlink would also allow us to rip the "I'm going to configure your newly installed kernel source tree so that stuff that depends on modules can compile code", which is problematic. Therefore, I lean strongly towards adopting jnelson's stance. Also, it is much more annoying to undo a change that was made without your consent than do something that wasn't done for you automatically. In the first case, you feel that you are odds with the automation technology. In the second case, there is no such conflict, even if you need to perform and additional step.
Fixed in new kernels; fixing this in all others now....