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
pgp6MPGDNdhNR.pgp
Description: PGP signature
