1 |
On 19/06/2014 21:17, gottlieb@×××.edu wrote: |
2 |
> (I am in the months long process of converting from testing to stable, |
3 |
> using the bothwick "going stable" method; but I don't believe that is |
4 |
> related to the question I am asking.) |
5 |
> |
6 |
> I was away for several days and have a number of problem with my |
7 |
> normally-daily update world. Some may be due to the testing-->stable |
8 |
> conversion but some I just don't understand at all. |
9 |
|
10 |
|
11 |
First thing: I understand why you want to go testing -> stable, but at |
12 |
least leave portage unstable. A *lot* of ancient stuff has been fixed in |
13 |
~arch, it's perfectly safe and robust, and most especially all that |
14 |
stupid "no parents that aren't satisfied by other packages in this slot" |
15 |
has gone away, replaced with something that a) works and b) makes sense |
16 |
and c) does not reduce the poor sysadmin (i.e you) to tears |
17 |
|
18 |
|
19 |
> |
20 |
> The first complaint is |
21 |
> |
22 |
> Conflict: 2 blocks (1 unsatisfied) |
23 |
> |
24 |
> !!! Multiple package instances within a single package slot have been pulled |
25 |
> !!! into the dependency graph, resulting in a slot conflict: |
26 |
> |
27 |
> dev-libs/openssl:0 |
28 |
> |
29 |
> (dev-libs/openssl-1.0.1h-r1::gentoo, installed) pulled in by |
30 |
> (no parents that aren't satisfied by other packages in this slot) |
31 |
> |
32 |
> (dev-libs/openssl-1.0.1h-r2::gentoo, ebuild scheduled for merge) pulled in by |
33 |
> >=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) |
34 |
> |
35 |
> I assume that the "no parents that aren't satisfied ..." means that |
36 |
> portage could handle this one. |
37 |
|
38 |
Yes, I believe that's how it worked. Portage was being unneccessarily |
39 |
verbose. If you need to you can always "emerge -1 openssl" to get past |
40 |
the messages |
41 |
|
42 |
> |
43 |
> There are a few more again with "no parents ...". Then comes one that I |
44 |
> can't understand |
45 |
> |
46 |
> virtual/libintl:0 |
47 |
> |
48 |
> (virtual/libintl-0-r1::gentoo, ebuild scheduled for merge) pulled in by |
49 |
> >=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) |
50 |
> |
51 |
> (virtual/libintl-0::gentoo, installed) pulled in by |
52 |
> =virtual/libintl-0 required by (net-analyzer/nmap-6.25::gentoo, installed) |
53 |
> (and 31 more with the same problem) |
54 |
> |
55 |
> This seems to say that nmap-6.25 requires specifically |
56 |
> virtual/libintl-0. But I went to net-analyzer/nmap-6.25.ebuild and the |
57 |
> only occurrence of libintl is |
58 |
> nls? ( virtual/libintl ) |
59 |
> in RDEPEND |
60 |
> |
61 |
> Why does this require specifically virtual/libintl-0 and not permit |
62 |
> virtual/libintl-0-r1? |
63 |
|
64 |
It's not nmap doing it, it is gnutls. Look again at the first line (for |
65 |
the -r1 version). Your gnutls is still ~arch and stable hasn't caught up |
66 |
yet. Run this |
67 |
|
68 |
emerge -1 gnutls |
69 |
|
70 |
then continue with your regular world update. |
71 |
|
72 |
In summary, when you get these weird blockers, always check if the |
73 |
higher number version is being pulled in by something ~arch. Then |
74 |
downgrade that offender manually. |
75 |
|
76 |
|
77 |
|
78 |
I would also advise you speed this along by doing this: |
79 |
|
80 |
emerge -av1 @system |
81 |
followed by a full @preserved-rebuild, depclean, revdep-rebuild (don't |
82 |
skimp on these 3, you want to check everything |
83 |
|
84 |
The system set updates slowly and can take forever for stable to catch |
85 |
up. Better to just get your critical base packages onto stable asap. |
86 |
|
87 |
Then the same for perl and python followed by the usual perl-cleaner and |
88 |
python-updater. It should be safe to let the rest of world update at |
89 |
it's own speed |
90 |
|
91 |
> |
92 |
> Any help would be appreciated. |
93 |
> allan |
94 |
> |
95 |
> |
96 |
> |
97 |
|
98 |
|
99 |
-- |
100 |
Alan McKinnon |
101 |
alan.mckinnon@×××××.com |