Re: [gentoo-user] update world problem (looks like slot confusion on my part)

[Alan McKinnon]

On 19/06/2014 21:17, gottlieb@×××.edu wrote:
> (I am in the months long process of converting from testing to stable,
> using the bothwick "going stable" method; but I don't believe that is
> related to the question I am asking.)
>
> I was away for several days and have a number of problem with my
> normally-daily update world.  Some may be due to the testing-->stable
> conversion but some I just don't understand at all.


First thing: I understand why you want to go testing -> stable, but at
least leave portage unstable. A *lot* of ancient stuff has been fixed in
~arch, it's perfectly safe and robust, and most especially all that
stupid "no parents that aren't satisfied by other packages in this slot"
has gone away, replaced with something that a) works and b) makes sense
and c) does not reduce the poor sysadmin (i.e you) to tears


>
> The first complaint is
>
>   Conflict: 2 blocks (1 unsatisfied)
>
>   !!! Multiple package instances within a single package slot have been pulled
>   !!! into the dependency graph, resulting in a slot conflict:
>
>   dev-libs/openssl:0
>
>     (dev-libs/openssl-1.0.1h-r1::gentoo, installed) pulled in by
>       (no parents that aren't satisfied by other packages in this slot)
>
>     (dev-libs/openssl-1.0.1h-r2::gentoo, ebuild scheduled for merge) pulled in by
>       >=dev-libs/openssl-1.0.1h-r2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (net-nds/openldap-2.4.38-r2::gentoo, installed)
>
> I assume that the "no parents that aren't satisfied ..." means that
> portage could handle this one.

Yes, I believe that's how it worked. Portage was being unneccessarily
verbose. If you need to you can always "emerge -1 openssl" to get past
the messages

>
> There are a few more again with "no parents ...".  Then comes one that I
> can't understand
>
>   virtual/libintl:0
>
>     (virtual/libintl-0-r1::gentoo, ebuild scheduled for merge) pulled in by
>       >=virtual/libintl-0-r1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (net-libs/gnutls-3.3.4::gentoo, ebuild scheduled for merge)
>
>     (virtual/libintl-0::gentoo, installed) pulled in by
>       =virtual/libintl-0 required by (net-analyzer/nmap-6.25::gentoo, installed)
>       (and 31 more with the same problem)
>
> This seems to say that nmap-6.25 requires specifically
> virtual/libintl-0.  But I went to net-analyzer/nmap-6.25.ebuild and the
> only occurrence of libintl is
>   	nls? ( virtual/libintl )
> in RDEPEND
>
> Why does this require specifically virtual/libintl-0 and not permit
> virtual/libintl-0-r1?

It's not nmap doing it, it is gnutls. Look again at the first line (for
the -r1 version). Your gnutls is still ~arch and stable hasn't caught up
yet. Run this

emerge -1 gnutls

then continue with your regular world update.

In summary, when you get these weird blockers, always check if the
higher number version is being pulled in by something ~arch. Then
downgrade that offender manually.



I would also advise you speed this along by doing this:

emerge -av1 @system
followed by a full @preserved-rebuild, depclean, revdep-rebuild (don't
skimp on these 3, you want to check everything

The system set updates slowly and can take forever for stable to catch
up. Better to just get your critical base packages onto stable asap.

Then the same for perl and python followed by the usual perl-cleaner and
python-updater. It should be safe to let the rest of world update at
it's own speed

>
> Any help would be appreciated.
> allan
>
>
>


-- 
Alan McKinnon
alan.mckinnon@×××××.com