On 03/02/2013 21:09, Dale wrote:
> Alan McKinnon wrote:
>> emerge -e --keep-going @world
>> shows output like this when a build fails:
>>
>> * One or more packages are either masked or have missing dependencies:
>> *
>> * >=dev-libs/icu-49:0/50= pulled in by:
>> * (x11-libs/qt-core-4.8.4-r1::gentoo, installed)
>>
>> I can't parse that. What kind of SLOT is "0/50=" ?
>>
>> So far this has happened twice. The packages that failed prior are not
>> important,
>> what is important is that when the depgraph is *recalculated*, I get
>> that error.
>> It's always that specific atom for icu causing issues and it's always
>> pulled in
>> by qt-<something>
>>
>> Anyone know what that atom means and if it's a bug or not?
>>
>> This system is ~amd64 and portage is latest masked 2.2.0_alpha161.
>> Active python is 2.7
>>
>
>
> LOL I'll give this a go, sort of. I get this for icu:
>
> root@fireball / # equery l -p icu
> * Searching for icu ...
> [IP-] [ ] dev-libs/icu-49.1.2:0
> [-P-] [ ~] dev-libs/icu-50.1-r1:0/50.1
> [-P-] [ ~] dev-libs/icu-50.1-r2:0/50.1
> [-P-] [ ~] dev-libs/icu-50.1.1:0/50.1.1
> root@fireball / #
>
> So, does it maybe want icu-50.* instead of the 49 that is installed?
> That would be equal to or greater than what you likely have. I might
> add, the 50 and above are keyworded.
>
> I took a stab at it but not sure what I hit. ;-)
It's confusing, lemme see if I can describe it, using the URL that
Michel O posted.
Your eix shows 4 versions of icu. Everything there up to the "/" chars
is normal and what you've been using for ages.
The "/" is sub-slots, introduced in EAPI=5. icu-49 uses a lesser EAPI so
it has no sub-slots. Each icu version >=50 is in SLOT 0, and it will
install .so files with the version after the "/".
So take my icu for example, it's version 50.1.1 and equery files reveals
it installs:
/usr/lib64/libicui18n.so.50.1.1
/usr/lib64/libicuio.so.50.1.1
/usr/lib64/libicule.so.50.1.1
Well whaddaya know, the .so version matches what eix claims (meaning the
icu ebuild is correctly declaring what it will provide).
That's one half of the story, the other half is with packages that
DEPEND on icu. qt-core for example has this:
icu? ( >=dev-libs/icu-49:= )
Now what that means is "qt-core DEPENDS on any version of icu >49, plus
the following: (this is the bit that's gonna bake your noodle)
If icu is re-emerged and that new version has a different .so version to
what the current version provides, then qt-core will break at run-time.
That's what the trailing = means, ie. qt-core depends on an icu that has
an soname equal to the one it has right now. In my case that is 50.1.1.
If I upgrade icu to a version with a different soname, then qt-core has
to be rebuilt, and now portage knows that.
There's another operator that can go where the "=" is and it's "*".
Which basically means "any". So if I have some package using EAPI=5 and
it has this line in DEPENDS:
icu? ( >=dev-libs/icu-49:* )
Then that would mean it depends on >icu-49 and the soname doesn't matter
as it can be any version. Presumably the devs did their homework and
figured out what their packages depend on, then put the right info in
their ebuilds. (I fear this last might be a tall order, but hey, we're
discussing syntax here, not human ability)
Is this all starting to sound maybe just a little bit like some magic
that will make @preserved-rebuild and revdep-rebuild redundant? We need
those tools because portage does not know what so versions will work
fine with what, and these sub-slots are supposed to give portage that
info. Whoopee.
;-)
Clear as mud now?
--
Alan McKinnon
alan.mckin...@gmail.com
