[gentoo-user] confusing emerge output

[gentoo-user] confusing emerge output

[Allan Gottlieb]

 # emerge --verbose --ask --deep --update --newuse --tree world 

gives just a few packages with dev-java/rhino the last one (first to
be merged).

But 

  # emerge --oneshot --ask rhino

Gives a bunch of packages with rhino the last one (last to build).

Could someone explain?
thanks,
allan

================================================================

Specifically

ajglap gottlieb # emerge --verbose --ask --deep --update --newuse --tree world

These are the packages that would be merged, in reverse order:

Calculating world dependencies... done!
[ebuild     U ] app-office/openoffice-2.4.0 [2.3.1-r1] USE="cups dbus firefox gnome gtk java pam -binfilter -branding% -debug -eds -gstreamer -kde -ldap -mono -odk -seamonkey -webdav -xulrunner (-cairo%) (-sound%*)" LINGUAS="-af -ar -as_IN -be_BY -bg -bn -br -bs -ca -cs -cy -da -de -dz -el -en -en_GB -en_US -en_ZA -eo -es -et -fa -fi -fr -ga -gl -gu_IN -he -hi_IN -hr -hu -it -ja -km -ko -ku -lt -lv -mk -ml_IN -mr_IN -nb -ne -nl -nn -nr -ns -or_IN -pa_IN -pl -pt -pt_BR -ru -rw -sh% -sk -sl -sr% -ss -st -sv -sw_TZ -ta_IN -te_IN -tg -th -ti_ER -tn -tr -ts -uk -ur_IN -ve -vi -xh -zh_CN -zh_TW -zu (-sh_YU%) (-sr_CS%)" 161,198 kB 
[ebuild     U ] x11-libs/qt-4.3.3 [4.3.2-r1] USE="accessibility cups dbus doc gif jpeg png qt3support* ssl tiff zlib -debug -examples -firebird -glib -mng -mysql -nas -nis -odbc -opengl -pch -postgres -sqlite -sqlite3 -xinerama" INPUT_DEVICES="-wacom" 41,350 kB 
[ebuild     U ] app-office/gnumeric-1.8.2 [1.8.1] USE="gnome perl python -debug" 13,747 kB 
[nomerge      ] app-office/openoffice-2.4.0 [2.3.1-r1] USE="cups dbus firefox gnome gtk java pam -binfilter -branding% -debug -eds -gstreamer -kde -ldap -mono -odk -seamonkey -webdav -xulrunner (-cairo%) (-sound%*)" LINGUAS="-af -ar -as_IN -be_BY -bg -bn -br -bs -ca -cs -cy -da -de -dz -el -en -en_GB -en_US -en_ZA -eo -es -et -fa -fi -fr -ga -gl -gu_IN -he -hi_IN -hr -hu -it -ja -km -ko -ku -lt -lv -mk -ml_IN -mr_IN -nb -ne -nl -nn -nr -ns -or_IN -pa_IN -pl -pt -pt_BR -ru -rw -sh% -sk -sl -sr% -ss -st -sv -sw_TZ -ta_IN -te_IN -tg -th -ti_ER -tn -tr -ts -uk -ur_IN -ve -vi -xh -zh_CN -zh_TW -zu (-sh_YU%) (-sr_CS%)" 
[ebuild  N    ]  dev-db/hsqldb-1.8.0.9  USE="doc -source" 3,412 kB 
[ebuild  NS   ]   dev-java/servletapi-2.3-r3  USE="doc -source" 125 kB 
[ebuild  N    ]  dev-java/rhino-1.5.5-r4  USE="doc -source" 1,506 kB 

Total: 6 packages (3 upgrades, 2 new, 1 in new slot), Size of downloads: 221,336 kB

Would you like to merge these packages? [Yes/No] no

Quitting.

ajglap gottlieb # emerge --oneshot --ask rhino

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    ] dev-java/junit-3.8.1-r3  USE="doc -source" 
[ebuild  N    ] dev-java/relaxng-datatype-1.0-r1  USE="doc -source" 
[ebuild  N    ] dev-java/icu4j-3.0-r1  USE="doc -source" 
[ebuild  N    ] dev-java/iso-relax-20050331-r1  USE="-source" 
[ebuild  N    ] dev-java/xpp2-2.1.10-r1  USE="doc -source" 
[ebuild  N    ] dev-java/xpp3-1.1.4c  USE="doc -source -test" 
[ebuild  N    ] dev-java/gnu-crypto-2.0.1-r2  USE="doc -source" 
[ebuild  N    ] dev-java/log4j-1.2.15  USE="doc -javamail -jms -jmx -source" 
[ebuild  N    ] dev-java/xsdlib-20050627-r1  USE="doc -source" 
[ebuild  N    ] dev-java/ant-junit-1.7.0  
[ebuild  N    ] dev-java/xom-1.0-r6  USE="doc -examples -source" 
[ebuild  N    ] dev-java/xmldb-20011111-r1  USE="doc -source" 
[ebuild  N    ] dev-java/jaxme-0.3.1-r4  USE="doc -source" 
[ebuild  N    ] dev-java/ant-trax-1.7.0  
[ebuild  N    ] dev-java/msv-20050627-r1  USE="doc -source" 
[ebuild  N    ] dev-java/saxpath-1.0-r2  USE="doc -source -test" 
[ebuild  N    ] dev-java/jsr173-1.0-r1  USE="doc -source" 
[ebuild  N    ] dev-java/dom4j-1.6.1-r2  USE="doc -source" 
[ebuild  N    ] dev-java/jdom-1.0-r4  USE="doc -examples -source" 
[ebuild  N    ] dev-java/jaxen-1.1.1  USE="doc -examples -source -test" 
[ebuild  N    ] dev-java/jdom-jaxen-1.0-r1  
[ebuild  N    ] dev-java/xml-xmlbeans-1.0.4_pre20041217  USE="doc -source" 
[ebuild  N    ] dev-java/rhino-1.6.5  USE="doc -examples -source" 

Would you like to merge these packages? [Yes/No] no

Quitting.

ajglap gottlieb # 
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] confusing emerge output

[Alan McKinnon]

On Wednesday 23 April 2008, Allan Gottlieb wrote:
>  # emerge --verbose --ask --deep --update --newuse --tree world
>
> gives just a few packages with dev-java/rhino the last one (first to
> be merged).
>
> But
>
>   # emerge --oneshot --ask rhino
>
> Gives a bunch of packages with rhino the last one (last to build).
>
> Could someone explain?

<snip>

> [ebuild  N    ]  dev-java/rhino-1.5.5-r4  USE="doc -source" 1,506 kB

<snip>

> [ebuild  N    ] dev-java/rhino-1.6.5  USE="doc -examples -source"

See the difference? One is v1.5 the other is v1.6. The explanation is in 
the full output of what rhino is and the openoffice ebuild:

alan@nazgul ~ $ eix rhino
* dev-java/rhino
     Available versions:
        (1.5)   1.5.5-r4
        (1.6)   1.6.5
        {doc elibc_FreeBSD examples source}
     Homepage:            http://www.mozilla.org/rhino/
     Description:         An open-source implementation of JavaScript 
written in Java.

From openoffice-2.4.0.ebuild:
COMMON_DEPEND="
            java? ( >=dev-java/bsh-2.0_beta4
                >=dev-java/xalan-2.7
                >=dev-java/xalan-serializer-2.7
                >=dev-java/xerces-2.7
                =dev-java/xml-commons-external-1.3*
                >=dev-db/hsqldb-1.8.0.9
                =dev-java/rhino-1.5* )"

There are two SLOTs for rhino - 1.5 and 1.6

OpenOffice explicitly DEPENDS on the 1.5 SLOT for rhino if you 
have "java" in USE. You probably have that so a deep world emerge will 
pull rhino-1.5* in.

You don't currently have rhino installed so when you issue "emerge 
rhino", portage will check for the latest one and install it. It just 
so happens that in this case, the latest is not the same SLOT that OOo 
wants.




-- 
Alan McKinnon
alan dot mckinnon at gmail dot com

--
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] confusing emerge output

[Allan Gottlieb]

At Wed, 23 Apr 2008 09:33:05 +0200 Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On Wednesday 23 April 2008, Allan Gottlieb wrote:
>>  # emerge --verbose --ask --deep --update --newuse --tree world
>>
>> gives just a few packages with dev-java/rhino the last one (first to
>> be merged).
>>
>> But
>>
>>   # emerge --oneshot --ask rhino
>>
>> Gives a bunch of packages with rhino the last one (last to build).
>>
>> Could someone explain?
>
> <snip>
>
>> [ebuild  N    ]  dev-java/rhino-1.5.5-r4  USE="doc -source" 1,506 kB
>
> <snip>
>
>> [ebuild  N    ] dev-java/rhino-1.6.5  USE="doc -examples -source"
>
> See the difference? One is v1.5 the other is v1.6. The explanation is in 
> the full output of what rhino is and the openoffice ebuild:
>
> alan@nazgul ~ $ eix rhino
> * dev-java/rhino
>      Available versions:
>         (1.5)   1.5.5-r4
>         (1.6)   1.6.5
>         {doc elibc_FreeBSD examples source}
>      Homepage:            http://www.mozilla.org/rhino/
>      Description:         An open-source implementation of JavaScript 
> written in Java.
>
> From openoffice-2.4.0.ebuild:
> COMMON_DEPEND="
>             java? ( >=dev-java/bsh-2.0_beta4
>                 >=dev-java/xalan-2.7
>                 >=dev-java/xalan-serializer-2.7
>                 >=dev-java/xerces-2.7
>                 =dev-java/xml-commons-external-1.3*
>                 >=dev-db/hsqldb-1.8.0.9
>                 =dev-java/rhino-1.5* )"
>
> There are two SLOTs for rhino - 1.5 and 1.6
>
> OpenOffice explicitly DEPENDS on the 1.5 SLOT for rhino if you 
> have "java" in USE. You probably have that so a deep world emerge will 
> pull rhino-1.5* in.
>
> You don't currently have rhino installed so when you issue "emerge 
> rhino", portage will check for the latest one and install it. It just 
> so happens that in this case, the latest is not the same SLOT that OOo 
> wants.

Crystal clear.  Thanks for the lucid and careful explanation.

allan
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] confusing emerge output

[Alan McKinnon]

On Wednesday 23 April 2008, Allan Gottlieb wrote:
> > You don't currently have rhino installed so when you issue "emerge
> > rhino", portage will check for the latest one and install it. It
> > just so happens that in this case, the latest is not the same SLOT
> > that OOo wants.
>
> Crystal clear.  Thanks for the lucid and careful explanation.

You're very welcome - emerge output can be ... um ... less than obvious 
at times.

I figure that the three years of blood, sweat and tears I spent figuring 
it out isn't worth very much if it all stays in my head and never gets 
out. I'm also building up karma credits for the hundreds of questions 
I'll be unleashing on the paludis user community one fine day very 
soon :-)

-- 
Alan McKinnon
alan dot mckinnon at gmail dot com

--
gentoo-user@lists.gentoo.org mailing list

[gentoo-user] confusing emerge output

[Michael P. Soulier]

[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]

Hi there,

I haven't updated in a while, and I went to do so today and received this

msoulier@anton:~$ emerge --update --pretend world

These are the packages that would be merged, in order:

Calculating dependencies... done!

!!! All ebuilds that could satisfy ">=app-admin/eselect-python-20090804" have
been masked.
!!! One of the following masked packages is required to complete your request:
- app-admin/eselect-python-99999999 (masked by: missing keyword)
- app-admin/eselect-python-20090824 (masked by: ~x86 keyword)
- app-admin/eselect-python-20090814 (masked by: ~x86 keyword)

For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.
(dependency required by "dev-python/django-1.1" [ebuild])
(dependency required by "world" [argument])

Is this saying that it can't update django without pulling in an unstable
eselect-python?

If so I'll just remove django for now...

Thanks,
Mike
-- 
Michael P. Soulier <msoulier@digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It takes a
touch of genius - and a lot of courage to move in the opposite direction."
--Albert Einstein

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-user] confusing emerge output

[Crístian Viana]

[-- Attachment #1: Type: text/plain, Size: 218 bytes --]

>
> Is this saying that it can't update django without pulling in an unstable
> eselect-python?
>

yes, but you're already using an unstable version of django.

-- 
Crístian Deives dos Santos Viana [aka CD1]

[-- Attachment #2: Type: text/html, Size: 376 bytes --]

Re: [gentoo-user] confusing emerge output

[Michael P. Soulier]

[-- Attachment #1: Type: text/plain, Size: 189 bytes --]

On 25/08/09 Crístian Viana said:

> yes, but you're already using an unstable version of django.

Not according to the Django developers. :) Anywho, I'll uninstall it for now.

Mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-user] Confusing emerge output

[Alan McKinnon]

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

-- 
alan.mckinnon@gmail.com

Re: [gentoo-user] Confusing emerge output

[Dale]

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.  ;-)

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] Confusing emerge output

[Michael Orlitzky]

On 02/03/2013 01:51 PM, 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?
> 

http://wiki.gentoo.org/wiki/Sub-slots_and_Slot-Operators

Re: [gentoo-user] Confusing emerge output

[Alan McKinnon]

On 03/02/2013 21:28, Michael Orlitzky wrote:
> On 02/03/2013 01:51 PM, 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?
>>
> 
> http://wiki.gentoo.org/wiki/Sub-slots_and_Slot-Operators

I'd already found much the same info in devmanual by the time I got and
read your reply. So let's see if I understand this now:

qt-core has this DEPEND:

        icu? ( >=dev-libs/icu-49:= )

My Qt is linked to this icu version:

        libicuuc.so.50 => /usr/lib64/libicuuc.so.50 (0x00007fa3a952c000)

But no version of icu in the tree provides that soname, as shown by eix:

     Available versions:  49.1.2 (~)50.1-r1(0/50.1) (~)50.1-r2(0/50.1)
(~)50.1.1(0/50.1.1) {debug doc examples static-libs}
     Installed versions:  50.1.1(09:40:50 15/01/2013)(-debug -doc
-examples -static-libs)

So, rebuilding Qt should trigger a rebuild of icu. Well, it doesn't
according to emerge -pv, but no matter. An emerge -e --keep-going @world
presumably will build icu-50.1.1, but when a package fails and the graph
is recalculated, something goes wrong.

Hmmm. bgo time.

https://bugs.gentoo.org/show_bug.cgi?id=455344

-- 
alan.mckinnon@gmail.com

Re: [gentoo-user] Confusing emerge output

[Alan McKinnon]

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.mckinnon@gmail.com

Re: [gentoo-user] Confusing emerge output

[Dale]

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!

Re: [gentoo-user] Confusing emerge output

[Alan McKinnon]

On 04/02/2013 01:22, Dale wrote:
>> 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? 


I'm a cynical old fart who's seen it all (more than once) before si I'm
inclined to reply with

"yes, portage is getting smarter about breakages"

and append to that

"by fixing one problem - revdep-rebuild - and introducing a vast slew of
new! shiny! improved! wonderful bugs that will make your life more
miserable than revdep-rebuild ever could!"

:-)

Now you go and have yourself a nice day, y'hear?



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Confusing emerge output

[Dale]

Alan McKinnon wrote:
> I'm a cynical old fart who's seen it all (more than once) before si
> I'm inclined to reply with "yes, portage is getting smarter about
> breakages" and append to that "by fixing one problem - revdep-rebuild
> - and introducing a vast slew of new! shiny! improved! wonderful bugs
> that will make your life more miserable than revdep-rebuild ever
> could!" :-) Now you go and have yourself a nice day, y'hear? 


Oh crap.  Now I see.  Oh boy.  This could be interesting, in a bad way. 
Is this breakage going to be like the udev thread that meant systems
could not boot after the upgrade?  One of those that sneaks up and kicks
you in the back of the knees? 

Back to my hole.  I may be there a while.  :/

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] Confusing emerge output

[Michael Orlitzky]

On 02/03/2013 04:00 PM, Alan McKinnon wrote:
>>
>> http://wiki.gentoo.org/wiki/Sub-slots_and_Slot-Operators
> 
> I'd already found much the same info in devmanual by the time I got and
> read your reply. So let's see if I understand this now:
> 

Beats me. I know what they're supposed to do, but haven't bothered to
figure out how they work yet.