Zac Medico schreef: > Holly Bostick wrote: > >> 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. >> <snip> > > 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.
..... OK, I understand this to some extent (meaning I get it that Portage is not going to be revised in this way), but I must question that last statement, "it seems desirable to compile against the latest kernel that is installed." The latest kernel that is *installed* (as opposed to the latest kernel whose source is emerged, regardless of whether it's configured, compiled, or installed) is the one I'm booted into, and while I presumably intend/want to upgrade to the newly emerged kernel at some reasonably soon point, I don't necessarily want to do it *right that minute*, nor am I necessarily going to avoid rebooting until such time as I have installed the upgraded kernel. > > 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: This sounds great, but what about the kernel I'm booted into, against which the module will *not* be compiled, if I have to reboot before actually configuring/compiling/installing the new kernel? The kernel modules will not be upgraded for that kernel (because the upgrades compiled only against the future kernel), and while that won't precisely break the old kernel (hopefully, since the old modules should still be good, though I cannot vouch for all circumstances), it means I don't have the upgraded modules for the currently-running kernel. After all, module-rebuild will re-build all the modules against a newly-compiled kernel; I don't need to build some limited subset of said modules against the new kernel source at the time I emerge the new kernel source, since I will build all of them at the end of the operations which make the new kernel actually available for use. What I do want is to build the upgraded modules against the currently-running kernel, which I expect to be using for some short additional period of time (until I compile and install the new kernel, which may be hours or days in the future). It would be nice to then have the future kernel source prepared for compilation and installation automatically (by redirecting the symlink), so that said compilation and installation goes on a "next-to-do, asap" list of sorts, but I'm not essentially forced to drop everything in order to compile the new kernel source *right now* in order to use the upgraded modules, which may be mission-critical in some respect (if the upgrade fixes functionality that I need working). Maybe the issue is really that the 'symlink' USE flag is obsolete in some respect, since it appears that automatic redirection of the /usr/src/linux symlink can often cause more problems than it solves, since the user cannot really know ahead of time whether a kernel module is going to upgrade in the same operation as a new kernel source is going to be emerged (which is not the same as installing a new kernel, of course). I guess I'll turn off the USE flag and manage the symlink directly, but it seems like there ought to be a better way. > > http://thread.gmane.org/gmane.linux.gentoo.portage.devel/1107 Thanks for the link. Holly -- gentoo-user@gentoo.org mailing list
