On Saturday 26 Nov 2005 10:12 pm, Holly Bostick wrote:
> ..... 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.
>
I don't know how portage designing works but what you are saying can probably 
never happen. What you want is that give "kernel" a special status and leave 
it out of dependency checking. How can that happen? If you follow the normal 
dependency checking then portage is working exactly how it should.

If we go by the way you want things to work then just imagine this scenario. 
Program abc depends on xyz. You have abc-1.0.0 as well as xyz-1.0.0 installed 
and configured on your system. Today both programs have been updated to 
versions 1.0.1 and you do emrge -uDNv world. What would be the desired action 
that portage should perform? The desired action would be to first update 
xyz-1.0.0 to xyz-1.0.1 and then build abc-1.0.1 against the newly installed 
libraries. What you want is that abc-1.0.1 should install against. xyz-1.0.0 
and then  you will revdep-rebuild later to build abc once again but this time 
against the newer xyz-1.0.1.

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.

Abhay