| 1 |
On Thu, Jun 19 2014, Alan McKinnon wrote: |
| 2 |
|
| 3 |
> On 19/06/2014 21:17, gottlieb@×××.edu wrote: |
| 4 |
>> |
| 5 |
>> There are a few more again with "no parents ...". Then comes one that I |
| 6 |
>> can't understand |
| 7 |
>> |
| 8 |
>> virtual/libintl:0 |
| 9 |
>> |
| 10 |
>> (virtual/libintl-0-r1::gentoo, ebuild scheduled for merge) pulled in by |
| 11 |
>> >=virtual/libintl-0-r1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] |
| 12 |
>> > required by (net-libs/gnutls-3.3.4::gentoo, ebuild scheduled |
| 13 |
>> > for merge) |
| 14 |
>> |
| 15 |
>> (virtual/libintl-0::gentoo, installed) pulled in by |
| 16 |
>> =virtual/libintl-0 required by (net-analyzer/nmap-6.25::gentoo, installed) |
| 17 |
>> (and 31 more with the same problem) |
| 18 |
>> |
| 19 |
>> This seems to say that nmap-6.25 requires specifically |
| 20 |
>> virtual/libintl-0. But I went to net-analyzer/nmap-6.25.ebuild and the |
| 21 |
>> only occurrence of libintl is |
| 22 |
>> nls? ( virtual/libintl ) |
| 23 |
>> in RDEPEND |
| 24 |
>> |
| 25 |
>> Why does this require specifically virtual/libintl-0 and not permit |
| 26 |
>> virtual/libintl-0-r1? |
| 27 |
> |
| 28 |
> It's not nmap doing it, it is gnutls. Look again at the first line (for |
| 29 |
> the -r1 version). Your gnutls is still ~arch and stable hasn't caught up |
| 30 |
> yet. Run this |
| 31 |
> |
| 32 |
> emerge -1 gnutls |
| 33 |
> |
| 34 |
> then continue with your regular world update. |
| 35 |
> |
| 36 |
> In summary, when you get these weird blockers, always check if the |
| 37 |
> higher number version is being pulled in by something ~arch. Then |
| 38 |
> downgrade that offender manually. |
| 39 |
|
| 40 |
I am trying to understand this but having difficulty. Perhaps the whole |
| 41 |
problem is caused by later complaints from portage asking me to keyword |
| 42 |
items. |
| 43 |
|
| 44 |
I understand that gnutls-3.3.4 needs the -r1 version of |
| 45 |
virtual/libintl-0. I don't understand why the other packages (nmap-6.25 |
| 46 |
and 31 others) are not happy with the -r1. Maybe this is just bad |
| 47 |
wording on portage's part and the real problem is that the -r1 version is |
| 48 |
keyworded and I am "going stable" without virtual/libintl in |
| 49 |
package.accept-keywords. |
| 50 |
|
| 51 |
I don't think that emerge -1 gnutls will help since it simply re-installs |
| 52 |
the stable 2.12.23-r6. |
| 53 |
|
| 54 |
The question is why do I need the testing gnutls-3.3.4 ? The answer |
| 55 |
according to portage (further down in the error messages) is |
| 56 |
|
| 57 |
The following keyword changes are necessary to proceed: |
| 58 |
(see "package.accept_keywords" in the portage(5) man page for more details) |
| 59 |
# required by net-im/empathy-3.10.3 |
| 60 |
# required by gnome-base/gnome-core-apps-3.10.0 |
| 61 |
# required by gnome-base/gnome-3.10.0 |
| 62 |
# required by @selected |
| 63 |
# required by @world (argument) |
| 64 |
=net-libs/gnutls-3.3.4 ~amd64 |
| 65 |
|
| 66 |
However I currently have empathy-3.10.3 and the ebuild for stable |
| 67 |
net-im/empathy-3.10.3 has in COMMON_DEPEND |
| 68 |
>=net-libs/gnutls-2.8.5:= |
| 69 |
|
| 70 |
My current gnutls is 2.12.23-r6. Is the problem the := ? Anyway I |
| 71 |
don't believe STABLE empathy should require TESTING gnutls. |
| 72 |
|
| 73 |
thanks again for helping and thanks in advance for clearing up my |
| 74 |
confusion. |
| 75 |
|
| 76 |
allan |
Archives