Holly Bostick wrote:
OK, I take it back.
I said that the situation of upgrading a kernel with the 'symlink' USE
flag active occurring at the same time as a (particular) program needing
to compile against a configured kernel was not likely to occur all that
often, but I was wrong. It's happened again today, but with a different
program than the ones I normally keep an eye on.
The good thing is that I (think I) see what the problem is.
The problem is that Portage emerges the new kernel before (almost)
everything else, without regard for whether the 'symlink' USE flag is
active, and whether or not any of the other programs proposed to emerge
need to compile against a configured kernel source-- or rather, the
currently-running kernel, which the symlink most likely pointed to
before Portage changed it via a previous emerge.
Honestly, there's really no reason (that I can see) to emerge a kernel
source before everything else, since the kernel source is useless until
at the very least configured, and preferably compiled and installed, and
since you're in the middle of an emerge -uwhatever world, you can't
reasonably configure and compile the new source until the entire
operation is finished. Yeah, OK, technically you can, but it's not
really something that an ordinary person would do, I think.
I like to manage the kernel sources myself so I always keep a kernel package in
package.provided.
mkdir -p /etc/portage/profile
echo sys-kernel/gentoo-sources-2.6.14-r3 >>
/etc/portage/profile/package.provided
And if the 'symlink' USE flag is active, emerging the kernel sources
before everything else-- which may include packages that must compile
against a configured kernel, with the assumption that the
/usr/src/symlink points to such a kernel, which it no longer does
because the symlink has been changed during a previous emerge and you
have not had time to configure the newly-emerged kernel-- is a real
problem. I just had to open another term, su to root, run MC to change
the symlink-- and got it wrong because I had a second unconfigured
kernel (2.6.14-r2; 2.6.14-r3 was being installed) that I forgot I had
not yet upgraded to), so had to change the link again to the *real*
running kernel (2.6.14) and emerge --resume. And of course I'll have to
eventually change the symlink back manually in order to actually manage
the new kernel. Which means I have to remember to do that-- which is not
the point of having the 'symlink' USE flag active.
It seems to me that this could all be avoided if Portage emerged a new
kernel *last* in the list if the 'symlink' USE flag is active for kernel
emerges-- then everything in the list that needed a configured kernel
would have one (the currently-running kernel), the emerge would complete
normally, and the symlink would be changed at the end of the procedure
so that my next operation could be to upgrade the kernel, which seems to
me a reasonable and ordinary order of operation (emerge -u** world, then
configure and compile new kernel and run module-rebuild).
Am I doing things wrong, or is this a valid enhancement request for b.g.o?
Holly
The portage developers will not add a special case for kernel packages, so any
reordering/prioritization would have to be done in a generic way that is usable
for any type of package. Also, it seems desireable to compile against the
latest kernel that is installed.
Perhaps it would make sense to have a default kernel config that is used to
configure the kernel sources automatically (make oldconfig; make
modules_prepare) after a new kernel is installed? Something like this could be
done ebuild postinst phase (when symlink is created). It is planned for future
versions of portage to have pre/post phase hooks, which will allow users to
define actions such as this via /etc/portage/bashrc:
http://thread.gmane.org/gmane.linux.gentoo.portage.devel/1107
Zac
--
gentoo-user@gentoo.org mailing list
