Alan McKinnon wrote: > 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? > >
< Dale scratches head > Hmmmm, that mud is pretty thick. May have to let that one sit for a bit to settle out. ^-^ So, portage is getting smarter about breakages then? Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
