Duncan wrote:
> Nikos Chantziaras <rea...@arcor.de> posted h0f7dm$9c...@ger.gmane.org,
> excerpted below, on  Sun, 07 Jun 2009 05:07:52 +0300:
> 
>> John P. Burkett wrote:
>>> Today on an amd64 machine I did
>>> emerge -D -uav world
>>> and got a response including the following lines: [...] I would be
>>> grateful for suggestions about how to resolve this blockage.
>> The rule of thumb: "by unmerging all packages that have the blockers and
>> running 'emerge -Duav world' again."
> 
> Yes.
> 
> In particular, in this instance, the old KDE 3.5.9 stuff is depending on 
> kde-base/kdelibs-3.5.9(-rWhatever), and KDE's now trying to upgrade to 
> 3.5.10(-rWhatever), but finding blockers because kdelibs is one of the 
> first upgrades, so you'd have the system in an inconsistent (according to 
> dependencies) state temporarily, after kdelibs has been upgraded to 
> 3.5.10 but before the other parts of KDE (kdebase, kdemultimedia, kdepim, 
> etc) have likewise been upgraded to 3.5.10.
> 
> Note that newer versions of portage have /automatic/ blocker resolution 
> in many temporary cases, so depending on how old your portage is (of 
> course I'm on ~amd64 and have had 3.5.10 for months now, and don't know 
> if the feature is in stable portage yet), if at the --ask prompt, you 
> tell it to go ahead, it may well take care of everything for you without 
> you having to do anything else. =:^)
>
> But, regardless of whether you have to fix it manually or not, note that 
> there may be a point during the merge where parts of KDE won't run 
> correctly, because you still have 3.5.9 components built against kdelibs 
> 3.5.9, trying to run against the new kdelibs 3.5.10.  It's unlikely (but 
> possible) KDE will crash if you are running it at the time, but until 
> everything gets brought back into consistency, you may have trouble 
> starting any new KDE apps.  If nothing else, plan to restart KDE (or 
> reboot entirely, tho that shouldn't be needed some people not 
> particularly comfortable at the shell prompt find it easier) when the 
> upgrade is done, so you get the benefit of all the new 3.5.10 goodness. 
> =:^)

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:
[blocks B     ] kde-base/kdenetwork ("kde-base/kdenetwork" is blocking
kde-base/kdelibs-3.5.10-r6)
[blocks B     ] kde-base/kde ("kde-base/kde" is blocking
kde-base/kdelibs-3.5.10-r6)
[blocks B     ] kde-base/kdetoys ("kde-base/kdetoys" is blocking
kde-base/kdelibs-3.5.10-r6)
[blocks B     ] kde-base/kdeaccessibility ("kde-base/kdeaccessibility"
is blocking kde-base/kdelibs-3.5.10-r6)
[blocks B     ] kde-base/kdeartwork ("kde-base/kdeartwork" is blocking
kde-base/kdelibs-3.5.10-r6)
[blocks B     ] kde-base/kdepim ("kde-base/kdepim" is blocking
kde-base/kdelibs-3.5.10-r6)
[blocks B     ] kde-base/kdemultimedia ("kde-base/kdemultimedia" is
blocking kde-base/kdelibs-3.5.10-r6)
[blocks B     ] kde-base/kdeadmin ("kde-base/kdeadmin" is blocking
kde-base/kdelibs-3.5.10-r6)
[blocks B     ] kde-base/kdebase ("kde-base/kdebase" is blocking
kde-base/kdelibs-3.5.10-r6)
[blocks B     ] kde-base/kdeedu ("kde-base/kdeedu" is blocking
kde-base/kdelibs-3.5.10-r6)
[blocks B     ] kde-base/kdegraphics ("kde-base/kdegraphics" is blocking
kde-base/kdelibs-3.5.10-r6)
[blocks B     ] kde-base/kdewebdev ("kde-base/kdewebdev" is blocking
kde-base/kdelibs-3.5.10-r6)
[blocks B     ] kde-base/kdegames ("kde-base/kdegames" is blocking
kde-base/kdelibs-3.5.10-r6)
[blocks B     ] kde-base/kdeaddons ("kde-base/kdeaddons" is blocking
kde-base/kdelibs-3.5.10-r6)
[blocks B     ] kde-base/kdeutils ("kde-base/kdeutils" is blocking
kde-base/kdelibs-3.5.10-r6)

Thus it appears that the blockage has to be resolved manually. Do you
recommend unmerging kdelibs or the 15 packages that are blocking it?

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?

Best regards,
John


-- 
John P. Burkett
Department of Economics
University of Rhode Island
Kingston, RI 02881-0808
USA

phone (401) 874-9195

Reply via email to