Duncan, Thanks to your help, my kde-base blockage is now resolved :-) Details of what worked are inserted below.
Duncan wrote: > "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? Yes, that is what I meant. > > 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. That worked. 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. > Doing "emerge kdebase-meta" seems to have worked for now. If other parts of kde are needed later, I'll try to add them then. Thanks again for you patient help! John -- John P. Burkett Department of Economics University of Rhode Island Kingston, RI 02881-0808 USA phone (401) 874-9195
