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 |