Re: [gentoo-amd64] Re: kde-base components blocking each other

[John P. Burkett]

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@×××.edu> posted 4A2BD1FA.6070206@×××.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 [phone]