1 |
On 03/02/2013 21:09, Dale wrote: |
2 |
> Alan McKinnon wrote: |
3 |
>> emerge -e --keep-going @world |
4 |
>> shows output like this when a build fails: |
5 |
>> |
6 |
>> * One or more packages are either masked or have missing dependencies: |
7 |
>> * |
8 |
>> * >=dev-libs/icu-49:0/50= pulled in by: |
9 |
>> * (x11-libs/qt-core-4.8.4-r1::gentoo, installed) |
10 |
>> |
11 |
>> I can't parse that. What kind of SLOT is "0/50=" ? |
12 |
>> |
13 |
>> So far this has happened twice. The packages that failed prior are not |
14 |
>> important, |
15 |
>> what is important is that when the depgraph is *recalculated*, I get |
16 |
>> that error. |
17 |
>> It's always that specific atom for icu causing issues and it's always |
18 |
>> pulled in |
19 |
>> by qt-<something> |
20 |
>> |
21 |
>> Anyone know what that atom means and if it's a bug or not? |
22 |
>> |
23 |
>> This system is ~amd64 and portage is latest masked 2.2.0_alpha161. |
24 |
>> Active python is 2.7 |
25 |
>> |
26 |
> |
27 |
> |
28 |
> LOL I'll give this a go, sort of. I get this for icu: |
29 |
> |
30 |
> root@fireball / # equery l -p icu |
31 |
> * Searching for icu ... |
32 |
> [IP-] [ ] dev-libs/icu-49.1.2:0 |
33 |
> [-P-] [ ~] dev-libs/icu-50.1-r1:0/50.1 |
34 |
> [-P-] [ ~] dev-libs/icu-50.1-r2:0/50.1 |
35 |
> [-P-] [ ~] dev-libs/icu-50.1.1:0/50.1.1 |
36 |
> root@fireball / # |
37 |
> |
38 |
> So, does it maybe want icu-50.* instead of the 49 that is installed? |
39 |
> That would be equal to or greater than what you likely have. I might |
40 |
> add, the 50 and above are keyworded. |
41 |
> |
42 |
> I took a stab at it but not sure what I hit. ;-) |
43 |
|
44 |
It's confusing, lemme see if I can describe it, using the URL that |
45 |
Michel O posted. |
46 |
|
47 |
Your eix shows 4 versions of icu. Everything there up to the "/" chars |
48 |
is normal and what you've been using for ages. |
49 |
|
50 |
The "/" is sub-slots, introduced in EAPI=5. icu-49 uses a lesser EAPI so |
51 |
it has no sub-slots. Each icu version >=50 is in SLOT 0, and it will |
52 |
install .so files with the version after the "/". |
53 |
|
54 |
So take my icu for example, it's version 50.1.1 and equery files reveals |
55 |
it installs: |
56 |
|
57 |
/usr/lib64/libicui18n.so.50.1.1 |
58 |
/usr/lib64/libicuio.so.50.1.1 |
59 |
/usr/lib64/libicule.so.50.1.1 |
60 |
|
61 |
Well whaddaya know, the .so version matches what eix claims (meaning the |
62 |
icu ebuild is correctly declaring what it will provide). |
63 |
|
64 |
That's one half of the story, the other half is with packages that |
65 |
DEPEND on icu. qt-core for example has this: |
66 |
|
67 |
icu? ( >=dev-libs/icu-49:= ) |
68 |
|
69 |
Now what that means is "qt-core DEPENDS on any version of icu >49, plus |
70 |
the following: (this is the bit that's gonna bake your noodle) |
71 |
|
72 |
If icu is re-emerged and that new version has a different .so version to |
73 |
what the current version provides, then qt-core will break at run-time. |
74 |
That's what the trailing = means, ie. qt-core depends on an icu that has |
75 |
an soname equal to the one it has right now. In my case that is 50.1.1. |
76 |
If I upgrade icu to a version with a different soname, then qt-core has |
77 |
to be rebuilt, and now portage knows that. |
78 |
|
79 |
There's another operator that can go where the "=" is and it's "*". |
80 |
Which basically means "any". So if I have some package using EAPI=5 and |
81 |
it has this line in DEPENDS: |
82 |
|
83 |
icu? ( >=dev-libs/icu-49:* ) |
84 |
|
85 |
Then that would mean it depends on >icu-49 and the soname doesn't matter |
86 |
as it can be any version. Presumably the devs did their homework and |
87 |
figured out what their packages depend on, then put the right info in |
88 |
their ebuilds. (I fear this last might be a tall order, but hey, we're |
89 |
discussing syntax here, not human ability) |
90 |
|
91 |
Is this all starting to sound maybe just a little bit like some magic |
92 |
that will make @preserved-rebuild and revdep-rebuild redundant? We need |
93 |
those tools because portage does not know what so versions will work |
94 |
fine with what, and these sub-slots are supposed to give portage that |
95 |
info. Whoopee. |
96 |
|
97 |
;-) |
98 |
|
99 |
Clear as mud now? |
100 |
|
101 |
|
102 |
-- |
103 |
Alan McKinnon |
104 |
alan.mckinnon@×××××.com |