On 20/06/2014 00:22, gottl...@nyu.edu wrote: > On Thu, Jun 19 2014, Alan McKinnon wrote: > >> On 19/06/2014 21:17, gottl...@nyu.edu wrote: >>> >>> 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 am trying to understand this but having difficulty. Perhaps the whole > problem is caused by later complaints from portage asking me to keyword > items. > > I understand that gnutls-3.3.4 needs the -r1 version of > virtual/libintl-0. I don't understand why the other packages (nmap-6.25 > and 31 others) are not happy with the -r1. Maybe this is just bad > wording on portage's part and the real problem is that the -r1 version is > keyworded and I am "going stable" without virtual/libintl in > package.accept-keywords. > > I don't think that emerge -1 gnutls will help since it simply re-installs > the stable 2.12.23-r6.
Ah, I see what it is. libintl is being pulled in by gnutls, which is being pulled in by something else (gnutls is scheduled for emerge). To find out what that something is, use emerge with -t These dependency chains can get long and complex, so best is usually to look at the whole thing and see exactly what is going on. Most often you have something in world that is keyworded, or the current version is still ~arch > > The question is why do I need the testing gnutls-3.3.4 ? The answer > according to portage (further down in the error messages) is > > The following keyword changes are necessary to proceed: > (see "package.accept_keywords" in the portage(5) man page for more details) > # required by net-im/empathy-3.10.3 > # required by gnome-base/gnome-core-apps-3.10.0 > # required by gnome-base/gnome-3.10.0 > # required by @selected > # required by @world (argument) > =net-libs/gnutls-3.3.4 ~amd64 > > However I currently have empathy-3.10.3 and the ebuild for stable > net-im/empathy-3.10.3 has in COMMON_DEPEND > >=net-libs/gnutls-2.8.5:= > > My current gnutls is 2.12.23-r6. Is the problem the := ? Anyway I > don't believe STABLE empathy should require TESTING gnutls. You are right, that output doesn't make sense, possibly you have some local config that is making it happen? Again -t will help sort out the chain. Something I find useful for these situations, take gnutls as an example: grep -ir gnutls /etc/portage finds everything I added to package.* and forgot about :-) My make.conf is in /etc/portage, if yours is still in /etc/ you'll have to grep that file as well > > thanks again for helping and thanks in advance for clearing up my > confusion. > > allan > > > -- Alan McKinnon alan.mckin...@gmail.com
