Notice in the output below that emerge thinks that 2.6.17-r8 is a later version than 2.6.18. +++++++++++++++++++++++++++++++ # emerge -Paq sys-kernel/gentoo-sources sys-kernel/gentoo-sources selected: 2.6.18 2.6.17-r7 protected: 2.6.17-r8 omitted: none
--prune has always been broken by design. I'd recommend --depclean, which works pretty well in >=portage-2.1.1.
(In reply to comment #1) > --prune has always been broken by design. I'd recommend --depclean, which > works pretty well in >=portage-2.1.1. How so? (I guess it depends on what you expect from it, but to my expectations it worked just fine so far). And --depclean can't be the replacement solution for this specific use case anyway, assuming gentoo-sources is in world, as it can't know if I care about the different slots or not (unless we record slot atoms in world which would be very new behavior).
(In reply to comment #2) > How so? (I guess it depends on what you expect from it, but to my expectations > it worked just fine so far). All that I meant is that it doesn't check dependencies (or even masking status?). I've never really used --prune but I know that it can be unsafe (just like --umerge though). I think --prune could be greatly improved if it used something similar to the depclean algorithm to ensure that it doesn't remove slots that are required by other packages.
--prune used to be the same as --unmerge except that it kept the highest version. Its main use (with these semantics) was to clean out old slots, in particular kernels (actually that's the only real use I can think of). Additionally protecting slots that are required by the depgraph makes sense, but doesn't change the fact that this bug (wrong version being protected) is valid.
The --prune code will use the counter, /var/db/pkg/sys-kernel/gentoo-sources-2.6.17-r8/COUNTER for example, to determine the most recently merged version (highest counter means most recently merged). Should we assume that the user wants to keep the most recently merged version or not?
(In reply to comment #5) > The --prune code will use the counter, > /var/db/pkg/sys-kernel/gentoo-sources-2.6.17-r8/COUNTER for example, to > determine the most recently merged version (highest counter means most recently > merged). Should we assume that the user wants to keep the most recently merged > version or not? > I thought --prune was supposed to keep the newest version level. Using gentoo-sources as an example, if one has 2.6.17, 2.6.18 and 2.6.18-r1 installed, --prune should unmerge all except 2.6.18-r1, regardless of when they were merged (but apparently that was wishful thinking on my part). In examining a system where the I see the problem still exhibited (one where I haven't manually unmerged the old kernels yet), I find this exhibited: ========================================== irobot ~ # emerge -Ppq gentoo-sources sys-kernel/gentoo-sources selected: 2.6.15-r4 2.6.15-r5 2.6.18 protected: 2.6.17-r5 omitted: none ========================================== How I thought --prune should work would be to unmerge everything except 2.6.18. However if the COUNTERS are examined: ========================================== gentoo-sources-2.6.15-r4/COUNTER = 3701 gentoo-sources-2.6.15-r5/COUNTER = 3813 gentoo-sources-2.6.17-r5/COUNTER = 4804 gentoo-sources-2.6.18/COUNTER = 4803 ========================================== So according to the counters gentoo-sources-2.6.17-r5 was emerged last. And genlop confirms this: ========================================== Tue Oct 10 02:31:55 2006 >>> sys-kernel/gentoo-sources-2.6.18 Tue Oct 10 02:33:53 2006 >>> sys-kernel/gentoo-sources-2.6.17-r5 ========================================== However, I never manually emerged 2.6.17-r5 after 2.6.18, the reversal must have occurred during something like an "emerge -e world" when I was rebuilding after a toolchain update, thereby causing --prune to exhibit unexpected behavior. So I guess in some ways this is my bad. If --prune worked as I thought it did then rebuilding world would not have caused this problem. Chris
(In reply to comment #6) > I thought --prune was supposed to keep the newest version level. Using > gentoo-sources as an example, if one has 2.6.17, 2.6.18 and 2.6.18-r1 > installed, --prune should unmerge all except 2.6.18-r1, regardless of when they > were merged. Correct. Well, "last version" in the manpage can be read both ways, but I'd say "highest version" is more useful and more deterministic than "most recently merged version" in this case. And changing existing behavior without a good reason isn't very nice anyway.
--prune (-P) WARNING: This action can remove important packages! Prune looks at each installed package and attempts to remove all but the most recently installed version. Prune ignores slots, if you require a slot-aware Prune use emerge --clean. Prune may inad- vertently remove important packages from your system. Use --clean instead unless you really know what you're doing. I just rewrote this manpage (should have been released in 2.1.2) for this exact reason. See "most recently installed" as opposed to highest version.
Created attachment 125408 [details, diff] keep the highest version whenever possible This is fixed in svn r7314.
This has been released in 2.1.3_rc9.