On 19/06/2014 21:17, [email protected] 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 [email protected]
