Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 2298 - vanilla-sources ebuild replaces /usr/src/linux symlink without asking
Summary: vanilla-sources ebuild replaces /usr/src/linux symlink without asking
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Daniel Robbins (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-04-30 23:14 UTC by Jon Nelson (RETIRED)
Modified: 2003-02-04 19:42 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jon Nelson (RETIRED) 2002-04-30 23:14:47 UTC
/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.
Comment 1 Daniel Robbins (RETIRED) gentoo-dev 2002-04-30 23:47:39 UTC
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.
Comment 2 Ryan Phillips (RETIRED) gentoo-dev 2002-05-01 02:22:49 UTC
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.
Comment 3 Jon Nelson (RETIRED) 2002-05-01 09:35:05 UTC
That's all I ask!
Thanks
Comment 4 Jon Nelson (RETIRED) 2002-05-01 10:11:48 UTC
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.

Comment 5 Arcady Genkin (RETIRED) gentoo-dev 2002-05-01 14:46:42 UTC
My vote is to disable mangling the symlink, letting the sys admin deal with it
manually.
Comment 6 Sandy McArthur 2002-05-01 16:23:46 UTC
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.
Comment 7 Troy Dack 2002-05-01 17:59:22 UTC
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.
Comment 8 Troy Dack 2002-05-01 19:49:53 UTC
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.
Comment 9 Daniel Robbins (RETIRED) gentoo-dev 2002-05-05 00:23:12 UTC
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.
Comment 10 Daniel Robbins (RETIRED) gentoo-dev 2002-05-08 00:54:10 UTC
Fixed in new kernels; fixing this in all others now....