Duncan,

Thanks to your help, my kde-base blockage is now resolved :-)
Details of what worked are inserted below.

Duncan wrote:
> "John P. Burkett" <burkett@...> posted 4A2BD1FA.6070206@...,
> 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