"John P. Burkett" <burk...@uri.edu> posted 4a2bd1fa.6070...@uri.edu, excerpted below, on Sun, 07 Jun 2009 10:43:06 -0400:
> Thank you, Duncan, for your thorough explanation. A few minutes ago I > reran eix-sync, updated portage to version 2.1.6.13, and tried "emerge > -D -uav world" and "emerge --pretend -NuD world". With both versions of > emerge, I still get the following messages: [snip the blocks] > Thus it appears that the blockage has to be resolved manually. Do you > recommend unmerging kdelibs or the 15 packages that are blocking it? It was in the longer post, but apparently got lost as a needle in a haystack... What I'm saying is that the blocks DO STILL show up on --pretend (and -- ask) because it's reporting that there are blocks requiring something to be done (uninstalls or whatever). However, most of the time, if you just do it (without the -p or saying y to -a), it'll go ahead and merge it anyway, taking care of the blocks when it gets to that specific point. Or are you saying you told it to go ahead, and it wouldn't do so, spitting out the errors, even when you told it to? If it's the latter, then the block is hard enough to resolve automatically that portage is taking the cautious approach and letting the admin tell it specifically what to do. In that case, see below... > The Gentoo handbook > http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked > says that the two options for fixing a blockage are to (1) "choose to > not install" the blocked package, or (2) unmerge the blocking packages. > Is the first option feasible when the blocked package is required by > world? If feasible, how would it be implemented? You can always unmerge almost any package (tho unmerging system packages without knowing what you are doing can get you in trouble, and I don't think it'll let you unmerge glibc, for instance, at all -- that's sort of the process equivalent of rm -rf .*, do NOT try either one!), regardless of its dependency status. If you unmerge something that's in world, it simply removes it from world during the unmerge. If you unmerge something that's a /dependency/ of something in world (say, kdelibs, as a dependency of pretty much anything kde), portage will let you do it, but you'll likely not be able to run whatever depended on it until you remerge the package or an upgrade in some form, and perhaps rebuild the world package so it properly links against the new form of its dependency. Now to explain what's happening with KDE... What you are seeing here is that KDE no longer has the monolithic versions with kde-3.5.10, only the split-package versions. You have the old monolithic versions of 3.5.9 installed as part of the kde package, which doesn't exist for 3.5.10. If you have the old kde package in world as it appears you do, it pulled in all the old monolithic kde major packages, kdelibs, kdebase, kdemultimedia, kdegraphics, etc, as dependencies. There's no kde-3.5.10 version of these packages, so portage is having problems. The direct equivalent would be kde-meta, with its dependencies, kdelibs (still a single package) kdebase-meta (which in turn depends on each individual package from kdebase, so konqueror, kcontrol, etc), kdemultimedia-meta (depending on all its individual packages), kdegrapics-meta, etc. If you want all of KDE, like the old kde package, it's (relatively) simple. Just unmerge kde. That should tell portage it's OK to get rid of the last available versions, 3.5.9, of all the monolithic packages, tho it won't itself unmerge any of them. After that, hopefully, you'll be able to merge kde-meta, and portage can figure out the rest of what it needs to do automatically. You should be able to tell because it should want to uninstall all of the old kdebase, kdemultimedia, etc type packages, and install the kde*-meta versions. The key is that it should now know what it can safely uninstall to get there from here. =:^) If that still doesn't work, you can unmerge the individual kde monolithic package, kdenetwork, kdeaccessibility, kdetoys, kdemultimedia, kdeadmin, kdebase, kdeedu, kdegraphics, kdewebdev, kdeaddons, kdeutils, since there aren't 3.5.10 versions of them anyway. Of course, you'll have to do this from a text console (or from GNOME or something if you have it installed), as that WILL remove your existing KDE. However, that should manually deal with the blockages entirely, tho stuff like amarok that depends on KDE but which is installed separately won't work either, until the new KDE is installed, something that can be avoided or at least the time without shortened a bit, if we can get portage handling the blocks itself. Meanwhile, at this upgrade is a good time to think a bit about what parts of KDE you actually use. If there are parts of kde you don't particularly want or need, it's now much easier to avoid having to install them and keep upgrading them every time you upgrade KDE. Say you don't use knode, which is part of kdepim, but want all of kdegraphics. You can now avoid merging knode by merging only the parts of kdepim (like say kmail) you want specifically instead of kde-meta or kdepim-meta, but since you still want all of kdegrapics, you can merge kdegrapics-meta. Just don't merge kdepim-meta or kde-meta, or you'll get knode and whatever other packages you avoided that make up the main distribution, as well. To see what individual parts each metapackage consists of, take a look at its ebuild. See all those kde-base/* RDEPENDS? If you don't want some of them, you may be able to avoid them by installing the individual packages you DO want instead of the meta-package that tells portage to install them all. -- 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
