Gentoo Archives: gentoo-user

From: Alan McKinnon <alan.mckinnon@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] update world problem (looks like slot confusion on my part)
Date: Fri, 20 Jun 2014 11:34:24
Message-Id: 53A41C06.3020707@gmail.com
In Reply to: Re: [gentoo-user] update world problem (looks like slot confusion on my part) by gottlieb@nyu.edu
1 On 20/06/2014 00:22, gottlieb@×××.edu wrote:
2 > On Thu, Jun 19 2014, Alan McKinnon wrote:
3 >
4 >> On 19/06/2014 21:17, gottlieb@×××.edu wrote:
5 >>>
6 >>> There are a few more again with "no parents ...". Then comes one that I
7 >>> can't understand
8 >>>
9 >>> virtual/libintl:0
10 >>>
11 >>> (virtual/libintl-0-r1::gentoo, ebuild scheduled for merge) pulled in by
12 >>> >=virtual/libintl-0-r1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]
13 >>> > required by (net-libs/gnutls-3.3.4::gentoo, ebuild scheduled
14 >>> > for merge)
15 >>>
16 >>> (virtual/libintl-0::gentoo, installed) pulled in by
17 >>> =virtual/libintl-0 required by (net-analyzer/nmap-6.25::gentoo, installed)
18 >>> (and 31 more with the same problem)
19 >>>
20 >>> This seems to say that nmap-6.25 requires specifically
21 >>> virtual/libintl-0. But I went to net-analyzer/nmap-6.25.ebuild and the
22 >>> only occurrence of libintl is
23 >>> nls? ( virtual/libintl )
24 >>> in RDEPEND
25 >>>
26 >>> Why does this require specifically virtual/libintl-0 and not permit
27 >>> virtual/libintl-0-r1?
28 >>
29 >> It's not nmap doing it, it is gnutls. Look again at the first line (for
30 >> the -r1 version). Your gnutls is still ~arch and stable hasn't caught up
31 >> yet. Run this
32 >>
33 >> emerge -1 gnutls
34 >>
35 >> then continue with your regular world update.
36 >>
37 >> In summary, when you get these weird blockers, always check if the
38 >> higher number version is being pulled in by something ~arch. Then
39 >> downgrade that offender manually.
40 >
41 > I am trying to understand this but having difficulty. Perhaps the whole
42 > problem is caused by later complaints from portage asking me to keyword
43 > items.
44 >
45 > I understand that gnutls-3.3.4 needs the -r1 version of
46 > virtual/libintl-0. I don't understand why the other packages (nmap-6.25
47 > and 31 others) are not happy with the -r1. Maybe this is just bad
48 > wording on portage's part and the real problem is that the -r1 version is
49 > keyworded and I am "going stable" without virtual/libintl in
50 > package.accept-keywords.
51 >
52 > I don't think that emerge -1 gnutls will help since it simply re-installs
53 > the stable 2.12.23-r6.
54
55 Ah, I see what it is. libintl is being pulled in by gnutls, which is
56 being pulled in by something else (gnutls is scheduled for emerge). To
57 find out what that something is, use emerge with -t
58
59 These dependency chains can get long and complex, so best is usually to
60 look at the whole thing and see exactly what is going on. Most often you
61 have something in world that is keyworded, or the current version is
62 still ~arch
63
64
65 >
66 > The question is why do I need the testing gnutls-3.3.4 ? The answer
67 > according to portage (further down in the error messages) is
68 >
69 > The following keyword changes are necessary to proceed:
70 > (see "package.accept_keywords" in the portage(5) man page for more details)
71 > # required by net-im/empathy-3.10.3
72 > # required by gnome-base/gnome-core-apps-3.10.0
73 > # required by gnome-base/gnome-3.10.0
74 > # required by @selected
75 > # required by @world (argument)
76 > =net-libs/gnutls-3.3.4 ~amd64
77 >
78 > However I currently have empathy-3.10.3 and the ebuild for stable
79 > net-im/empathy-3.10.3 has in COMMON_DEPEND
80 > >=net-libs/gnutls-2.8.5:=
81 >
82 > My current gnutls is 2.12.23-r6. Is the problem the := ? Anyway I
83 > don't believe STABLE empathy should require TESTING gnutls.
84
85 You are right, that output doesn't make sense, possibly you have some
86 local config that is making it happen? Again -t will help sort out the
87 chain.
88
89 Something I find useful for these situations, take gnutls as an example:
90
91 grep -ir gnutls /etc/portage
92
93 finds everything I added to package.* and forgot about :-)
94 My make.conf is in /etc/portage, if yours is still in /etc/ you'll have
95 to grep that file as well
96
97
98
99
100 >
101 > thanks again for helping and thanks in advance for clearing up my
102 > confusion.
103 >
104 > allan
105 >
106 >
107 >
108
109
110 --
111 Alan McKinnon
112 alan.mckinnon@×××××.com

Replies

Subject Author
Re: [gentoo-user] update world problem (looks like slot confusion on my part) Neil Bothwick <neil@××××××××××.uk>