Summary: | vanilla-sources ebuild always creates /usr/src/linux symlink | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dirk Heinrichs <dirk.heinrichs.ext> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED WONTFIX | ||
Severity: | trivial | ||
Priority: | High | ||
Version: | 2005.1 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Dirk Heinrichs
2006-03-26 23:08:24 UTC
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/ |