Re: [gentoo-user] autounmask not doing to well

[Alan McKinnon]

Apparently, though unproven, at 04:58 on Friday 17 September 2010, Dale did 
opine thusly:

> Hi folks,
>
> The latest KDE 4.5.1 has hit the tree.  It made it there a few days
> ago.  Yeppie!!  It is masked but I wanted to try to install it again.
> The last time was a mess to say it lightly.  I use autounmask to unmask
> it.  I use this command:
>
> autounmask kde-base/kde-meta-4.5.1
>
> I don't use the -n option but it doesn't seem to matter even if I do.
> I'm on portage-2.2_rc67 and autounmask-0.27 which is the only version I
> see in the tree.  After I run autounmask and then do a emerge -uvDNa
> world, I get this:
>
> root@smoker / # emerge -uvDNa world
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
>
> emerge: there are no ebuilds to satisfy
> ">=kde-base/kdelibs-9999[-kdeprefix,-aqua]".
> (dependency required by "kde-base/liboxygenstyle-9999" [installed])
> (dependency required by "kde-base/kdebase-meta-4.5.1" [ebuild])
> (dependency required by "kde-base/kde-meta-4.5.1" [ebuild])
> (dependency required by "@world" [argument])
>
> root@smoker / #
>
> If I add that kdelibs package to the unmask file, it just goes to the
> nest blocker and this continues until I get the idea something is not
> working right.  So, is autounmask not working right?  Am I not doing
> something right?  Am I missing something?


It's not kdelibs that's your problem, it is liboxygen style. portage wants to 
use version 9999 from svn and it's that that is pulling in kdelibs.

Fix your unmask for liboxygenstyle, then see with -t why it wants the -9999 
version


-- 
alan dot mckinnon at gmail dot com