Re: [gentoo-user] How does Portage prioritze emerges in emerge world?
On Sat, 26 Nov 2005 18:47:38 +0100, Holly Bostick wrote: 1) disable the symlink USE flag and manage the redirect manually, which would enable me to download any kernel at any time without concern for whether a kernel module was upgrading in the same operation; or That's one approach. In some ways it is the easiest, especially if you already have a script that deals with copying the config, running make oldconfig and mounting /boot to avoid forgetting this later. The route I chose was to emerge the kernel sources first when they show up in emerge -u world. Then compile and install the new kernel before rebooting and running emerge world again. Thinking about it, removing the symlink USE flag may be easier. -- Neil Bothwick Bus: (n.) a connector you plug money into, something like a slot machine. signature.asc Description: PGP signature
Re: [gentoo-user] How does Portage prioritze emerges in emerge world?
Abhay Kedia [EMAIL PROTECTED] writes: imho that is certainly not the way things should work. Why not build with latest libraries when you already have them? To do what you want, all kernel packages will have to be left alone from dependency tracking and I don't know whether it is possible or not. Just my 2 cents. Another way of doing it would be for portage to stop after 'installing' a kernel upgrade. Then you would configure and (possibly build) the new kernel before restarting portage. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] How does Portage prioritze emerges in emerge world?
On Sat, 26 Nov 2005 14:06:02 +0100 Holly Bostick [EMAIL PROTECTED] wrote: | Am I doing things wrong, or is this a valid enhancement request for | b.g.o? Unlikely to happen... Dependency resolution doesn't work that way. -- Ciaran McCreesh : Gentoo Developer (The one that looks before leaping) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-user] How does Portage prioritze emerges in emerge world?
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
Re: [gentoo-user] How does Portage prioritze emerges in emerge world?
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
Re: [gentoo-user] How does Portage prioritze emerges in emerge world?
Holly Bostick wrote: 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? You can get pretty close to your desired behavior (merge kernel last) if you simple mask kernel package versions greater than the one that is currently installed. mkdir -p /etc/portage echo sys-kernel/gentoo-sources-2.6.14-r2 /etc/portage/package.mask That way, portage will not attempt to upgrade it until you tell it that you are ready, by removing the mask. And yeah, if USE=symlink causes problems, don't use it (in my suggested scenario above it might be useful though). Zac -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] How does Portage prioritze emerges in emerge world?
Zac Medico schreef: Holly Bostick wrote: 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? You can get pretty close to your desired behavior (merge kernel last) if you simple mask kernel package versions greater than the one that is currently installed. mkdir -p /etc/portage echo sys-kernel/gentoo-sources-2.6.14-r2 /etc/portage/package.mask That way, portage will not attempt to upgrade it until you tell it that you are ready, by removing the mask. And yeah, if USE=symlink causes problems, don't use it (in my suggested scenario above it might be useful though). So the ultimate conclusion is that I can either 1) disable the symlink USE flag and manage the redirect manually, which would enable me to download any kernel at any time without concern for whether a kernel module was upgrading in the same operation; or 2) manually mask kernels, which would enable me to upgrade any kernel modules at any time but force me to manually oversee the availability of kernel upgrades and manually enable them (and re-disable them following said upgrade). I guess I'll go for option 1, but the long and the short of it is that complete automation is unavailable and my only choice is what I prefer to manage manually. OK, then. sigh Thanks. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] How does Portage prioritze emerges in emerge world?
On Sun, 27 Nov 2005 06:47, Holly Bostick wrote: 1) disable the symlink USE flag and manage the redirect manually, which would enable me to download any kernel at any time without concern for whether a kernel module was upgrading in the same operation; or snip I guess I'll go for option 1, but the long and the short of it is that complete automation is unavailable and my only choice is what I prefer to manage manually. OK, then. sigh Thanks. Holly Yeah it would be nice if there was a system to manage this, but your solution works for me too and its relatively easy to remember what you need to fix when you do a kernel upgrade. I get the feeling that automating this sort of thing is non-trivial. Besides... are we gentoo users or what?! ;) -- Ozmosis: The inability of one's job to live up to one's self-image. -- Douglas Coupland, Generation X: Tales for an Accelerated Culture -- gentoo-user@gentoo.org mailing list
