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. 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 -- gentoo-user@gentoo.org mailing list
