Bo Ørsted Andresen <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Mon, 29 Jan 2007 11:31:46 +0100:
> I didn't really have the patience to read all the way through your post but > this part does appear to be incorrect. > > The world file can only contain package names (neither slots nor versions) so > removing kde-3.4 while keeping kde-3.5 is not going to change what's in the > world file. If something in the world file depends on kdelibs-3.5 then > `emerge --depclean` will not remove kdelibs-3.4 or any other old slots that > really aren't needed anymore. > > Only --prune or --unmerge will do that and both of those currently have the > downside that they don't check whether it's still needed (as in the case of > autoconf, automake etc.). Implementing a safer --prune reusing some of the > code from --depclean (which was improved a lot in portage-2.1.1) has been > discussed in the past but it isn't done yet. Thanks for the correction. While I knew that world doesn't contain slots or versions, I thought (and believe it works that way in ~portage, but it may not have reached stable yet, and I could be wrong) that unmerging the metapackage would then release the dependency on the other stuff in that slot. For KDE monolithics, for instance, I believe(d) that while old kdelibs won't be unmerged immediately as it isdepended on by kdebase which is depended on by (among others) kdegraphics, without the old kde-3.4.x, kdegraphics-3.4.x would be trimmed by --depclean, and once all the other kdewhatever-3.4.x packages had been trimmed, then kdebase-3.4.x could be trimmed, and then kdelibs-3.4.x. However, I'm using the split packages, not the monolithics, and don't have kde-meta merged as I don't need all the split packages either. That makes it harder to test. In addition, I unmerge old versions pretty quickly once I've upgraded and found no critical non-working stuff (like say konqueror or kmail, or anything having to do with the ability to run a KDE desktop itself), keeping up with that system maintenance, so I've never gotten to the point of having that much cruft to unmerge at once. Thus, that part wasn't tested, and you (naturally) had to call me on it. =8^) Still, genuinely, thanks, as if I'm not called on such things, I get lax, and it's those I'm trying to help that get hurt, so I'd much rather get called on my errors than not! -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [email protected] mailing list
