[gentoo-user] Updating libpng: another libtool cockup?

[gentoo-user] Updating libpng: another libtool cockup?

[walt]

I just did a routine update on my ~amd64 machine and saw the portage
warning that libpng14 has been replaced by libpng15, and I should run
revdep-rebuild --library '/usr/lib/libpng14.so' and then delete the
obsolete library.

That's what I did.  I confess I wasn't watching, so I may have missed
some important errors during the run.

After that I ran plain revdep-rebuild as I do after every update, and
saw that two gnome packages failed to rebuild properly because lpng14
couldn't be found :/

From painful experience I've learned that good-old libtool files (*.la)
are the usual suspects, and grep found -lpng14 in about ten .la files
even after both revdep-rebuilds.  Grrr!

This fixed the problem for me (as similar moves have done in the past):

#find /usr/lib64 -name \*.la -exec sed -i s/png14/png15/ '{}' ';'

I ran revdep-rebuild again and the two broken packages emerged nicely
this time.

I hope no one else will hit this problem, but at least this is a good
workaround if you do.

Re: [gentoo-user] Updating libpng: another libtool cockup?

[Michael Mol]

On Sun, Sep 18, 2011 at 4:10 PM, walt <w41ter@gmail.com> wrote:
> I just did a routine update on my ~amd64 machine and saw the portage
> warning that libpng14 has been replaced by libpng15, and I should run
> revdep-rebuild --library '/usr/lib/libpng14.so' and then delete the
> obsolete library.
>
> That's what I did.  I confess I wasn't watching, so I may have missed
> some important errors during the run.
>
> After that I ran plain revdep-rebuild as I do after every update, and
> saw that two gnome packages failed to rebuild properly because lpng14
> couldn't be found :/
>
> From painful experience I've learned that good-old libtool files (*.la)
> are the usual suspects, and grep found -lpng14 in about ten .la files
> even after both revdep-rebuilds.  Grrr!
>
> This fixed the problem for me (as similar moves have done in the past):
>
> #find /usr/lib64 -name \*.la -exec sed -i s/png14/png15/ '{}' ';'
>
> I ran revdep-rebuild again and the two broken packages emerged nicely
> this time.
>
> I hope no one else will hit this problem, but at least this is a good
> workaround if you do.

If you're not following Diego Pettenò's blog, you probably should. .la
files are one of the things he harps on in his blog.

http://blog.flameeyes.eu/

-- 
:wq

Re: [gentoo-user] Updating libpng: another libtool cockup?

[Thanasis]

on 09/18/2011 11:10 PM walt wrote the following:
> I just did a routine update on my ~amd64 machine and saw the portage
> warning that libpng14 has been replaced by libpng15, and I should run
> revdep-rebuild --library '/usr/lib/libpng14.so' and then delete the
> obsolete library.
><snip>
> This fixed the problem for me (as similar moves have done in the past):
> 
> #find /usr/lib64 -name \*.la -exec sed -i s/png14/png15/ '{}' ';'

Thanks ! I didn't know we can just edit .la files.

Re: [gentoo-user] Updating libpng: another libtool cockup?

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 706 bytes --]

On Sunday 18 Sep 2011 21:57:29 Thanasis wrote:
> on 09/18/2011 11:10 PM walt wrote the following:
> > I just did a routine update on my ~amd64 machine and saw the portage
> > warning that libpng14 has been replaced by libpng15, and I should run
> > revdep-rebuild --library '/usr/lib/libpng14.so' and then delete the
> > obsolete library.
> >
> ><snip>
> >
> > This fixed the problem for me (as similar moves have done in the past):
> > 
> > #find /usr/lib64 -name \*.la -exec sed -i s/png14/png15/ '{}' ';'
> 
> Thanks ! I didn't know we can just edit .la files.

Isn't something like this that lafilefixer does (and now is part of the 
default FEATURES in portage)?
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Updating libpng: another libtool cockup?

[Allan Gottlieb]

On Sun, Sep 18 2011, walt wrote:

> I just did a routine update on my ~amd64 machine and saw the portage
> warning that libpng14 has been replaced by libpng15, and I should run
> revdep-rebuild --library '/usr/lib/libpng14.so' and then delete the
> obsolete library.
>
> After that I ran plain revdep-rebuild as I do after every update, and
> saw that two gnome packages failed to rebuild properly because lpng14
> couldn't be found :/
>
> From painful experience I've learned that good-old libtool files (*.la)
> are the usual suspects, and grep found -lpng14 in about ten .la files
> even after both revdep-rebuilds.  Grrr!
>
> This fixed the problem for me (as similar moves have done in the past):
>
> #find /usr/lib64 -name \*.la -exec sed -i s/png14/png15/ '{}' ';'

Thanks for the tip.  I wonder when a routing update world tells you to
run
   revdep-rebuild --library <some-lib>
should you run it before or after the normal
   revdep-rebuild
that we normally run after updates?

thanks,
allan

Re: [gentoo-user] Updating libpng: another libtool cockup?

[Alan McKinnon]

On Sun, 18 Sep 2011 17:58:14 -0400
Allan Gottlieb <gottlieb@nyu.edu> wrote:

> On Sun, Sep 18 2011, walt wrote:
> 
> > I just did a routine update on my ~amd64 machine and saw the portage
> > warning that libpng14 has been replaced by libpng15, and I should
> > run revdep-rebuild --library '/usr/lib/libpng14.so' and then delete
> > the obsolete library.
> >
> > After that I ran plain revdep-rebuild as I do after every update,
> > and saw that two gnome packages failed to rebuild properly because
> > lpng14 couldn't be found :/
> >
> > From painful experience I've learned that good-old libtool files
> > (*.la) are the usual suspects, and grep found -lpng14 in about
> > ten .la files even after both revdep-rebuilds.  Grrr!
> >
> > This fixed the problem for me (as similar moves have done in the
> > past):
> >
> > #find /usr/lib64 -name \*.la -exec sed -i s/png14/png15/ '{}' ';'
> 
> Thanks for the tip.  I wonder when a routing update world tells you to
> run
>    revdep-rebuild --library <some-lib>
> should you run it before or after the normal
>    revdep-rebuild
> that we normally run after updates?

Neither. 

revdep-rebuild checks everything, revdep-rebuild --library
checks just some things.

ebuilds sometimes issue messages to check just the libraries known to
have been updated, but a full revdep-rebuild after an update will catch
those anyway.


-- 
Alan McKinnnon
alan.mckinnon@gmail.com

[gentoo-user] Re: Updating libpng: another libtool cockup?

[walt]

On Mon, 2011-09-19 at 01:39 +0200, Alan McKinnon wrote:
> On Sun, 18 Sep 2011 17:58:14 -0400
> Allan Gottlieb <gottlieb@nyu.edu> wrote:
> 
> > On Sun, Sep 18 2011, walt wrote:
> > 
> > > I just did a routine update on my ~amd64 machine and saw the portage
> > > warning that libpng14 has been replaced by libpng15, and I should
> > > run revdep-rebuild --library '/usr/lib/libpng14.so' and then delete
> > > the obsolete library.
> > >
> > > After that I ran plain revdep-rebuild as I do after every update,
> > > and saw that two gnome packages failed to rebuild properly because
> > > lpng14 couldn't be found :/
> > >
> > > From painful experience I've learned that good-old libtool files
> > > (*.la) are the usual suspects, and grep found -lpng14 in about
> > > ten .la files even after both revdep-rebuilds.  Grrr!
> > >
> > > This fixed the problem for me (as similar moves have done in the
> > > past):
> > >
> > > #find /usr/lib64 -name \*.la -exec sed -i s/png14/png15/ '{}' ';'
> > 
> > Thanks for the tip.  I wonder when a routing update world tells you to
> > run
> >    revdep-rebuild --library <some-lib>
> > should you run it before or after the normal
> >    revdep-rebuild
> > that we normally run after updates?
> 
> Neither. 
> 
> revdep-rebuild checks everything, revdep-rebuild --library
> checks just some things.
> 
> ebuilds sometimes issue messages to check just the libraries known to
> have been updated, but a full revdep-rebuild after an update will catch
> those anyway.

Until recently I skipped the "--library" step exactly because I knew
revdep-rebuild will find and fix the broken packages after I delete
the old library.  So, why bother with the --library step, right?

However.  A few weeks ago I got caught when I deleted one of those
obsolete libraries and only then did I find out that gcc is one of
the packages that depend on it :(

I don't skip the --library step any more.

Re: [gentoo-user] Updating libpng: another libtool cockup?

[Allan Gottlieb]

On Sun, Sep 18 2011, Alan McKinnon wrote:

> On Sun, 18 Sep 2011 17:58:14 -0400
> Allan Gottlieb <gottlieb@nyu.edu> wrote:
>
>> I wonder when a routine update world tells you to run
>>    revdep-rebuild --library <some-lib>
>> should you run it before or after the full
>>    revdep-rebuild
>> that we normally run after updates?
>
> Neither. 
>
> revdep-rebuild checks everything, revdep-rebuild --library
> checks just some things.
>
> ebuilds sometimes issue messages to check just the libraries known to
> have been updated, but a full revdep-rebuild after an update will catch
> those anyway.

thanks,
allan

Re: [gentoo-user] Re: Updating libpng: another libtool cockup?

[Alan McKinnon]

On Mon, 19 Sep 2011 03:06:30 -0700
walt <w41ter@gmail.com> wrote:

> On Mon, 2011-09-19 at 01:39 +0200, Alan McKinnon wrote:
> > On Sun, 18 Sep 2011 17:58:14 -0400
> > Allan Gottlieb <gottlieb@nyu.edu> wrote:
> > 
> > > On Sun, Sep 18 2011, walt wrote:
> > > 
> > > > I just did a routine update on my ~amd64 machine and saw the
> > > > portage warning that libpng14 has been replaced by libpng15,
> > > > and I should run revdep-rebuild --library
> > > > '/usr/lib/libpng14.so' and then delete the obsolete library.
> > > >
> > > > After that I ran plain revdep-rebuild as I do after every
> > > > update, and saw that two gnome packages failed to rebuild
> > > > properly because lpng14 couldn't be found :/
> > > >
> > > > From painful experience I've learned that good-old libtool files
> > > > (*.la) are the usual suspects, and grep found -lpng14 in about
> > > > ten .la files even after both revdep-rebuilds.  Grrr!
> > > >
> > > > This fixed the problem for me (as similar moves have done in the
> > > > past):
> > > >
> > > > #find /usr/lib64 -name \*.la -exec sed -i s/png14/png15/ '{}'
> > > > ';'
> > > 
> > > Thanks for the tip.  I wonder when a routing update world tells
> > > you to run
> > >    revdep-rebuild --library <some-lib>
> > > should you run it before or after the normal
> > >    revdep-rebuild
> > > that we normally run after updates?
> > 
> > Neither. 
> > 
> > revdep-rebuild checks everything, revdep-rebuild --library
> > checks just some things.
> > 
> > ebuilds sometimes issue messages to check just the libraries known
> > to have been updated, but a full revdep-rebuild after an update
> > will catch those anyway.
> 
> Until recently I skipped the "--library" step exactly because I knew
> revdep-rebuild will find and fix the broken packages after I delete
> the old library.  So, why bother with the --library step, right?
> 
> However.  A few weeks ago I got caught when I deleted one of those
> obsolete libraries and only then did I find out that gcc is one of
> the packages that depend on it :(
> 
> I don't skip the --library step any more.

That's odd behaviour, I wonder what caused the difference.

Surely revdep-rebuild itself can't do this different just because you
specified a library to compare? I wonder if that lib was maybe in the
revdep-rebuild exclude list.

I'd be interested to track it down for reference, do you remember the
library involved?


-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Updating libpng: another libtool cockup?

[Allan Gottlieb]

On Mon, Sep 19 2011, Alan McKinnon wrote:

>> > revdep-rebuild checks everything, revdep-rebuild --library
>> > checks just some things.
>> > 
>> > ebuilds sometimes issue messages to check just the libraries known
>> > to have been updated, but a full revdep-rebuild after an update
>> > will catch those anyway.
>> 
>> Until recently I skipped the "--library" step exactly because I knew
>> revdep-rebuild will find and fix the broken packages after I delete
>> the old library.  So, why bother with the --library step, right?
>> 
>> However.  A few weeks ago I got caught when I deleted one of those
>> obsolete libraries and only then did I find out that gcc is one of
>> the packages that depend on it :(
>> 
>> I don't skip the --library step any more.
>
> That's odd behaviour, I wonder what caused the difference.
>
> Surely revdep-rebuild itself can't do this different just because you
> specified a library to compare? I wonder if that lib was maybe in the
> revdep-rebuild exclude list.
>
> I'd be interested to track it down for reference, do you remember the
> library involved?

It occurs exactly in the case we are discussing libpng

ajglap gottlieb # revdep-rebuild; revdep-rebuild --library '/usr/lib64/libpng14.so.14'
 * Configuring search environment for revdep-rebuild

 * Checking reverse dependencies
 * Packages containing binaries and libraries broken by a package update
 * will be emerged.

 * Collecting system binaries and libraries
 * Generated new 1_files.rr
 * Collecting complete LD_LIBRARY_PATH
 * Generated new 2_ldpath.rr
 * Checking dynamic linking consistency
[ 100% ]                 

 * Dynamic linking on your system is consistent... All done. 
 * Configuring search environment for revdep-rebuild

 * Checking reverse dependencies
 * Packages containing binaries and libraries using /usr/lib64/libpng14.so.14
 * will be emerged.

 * Collecting system binaries and libraries
 * Generated new 1_files.rr
 * Checking dynamic linking 
[ 8% ]  *   found /usr/bin/dia
[ 46% ]  *   found /usr/lib64/dia/libaadl_objects.so
 *   found /usr/lib64/dia/libart_filter.so
 *   found /usr/lib64/dia/libcairo_filter.so
 *   found /usr/lib64/dia/libcgm_filter.so
 *   found /usr/lib64/dia/libchronogram_objects.so
 *   found /usr/lib64/dia/libcustom_lines_objects.so
 *   found /usr/lib64/dia/libcustom_objects.so
 *   found /usr/lib64/dia/libdb_objects.so
 *   found /usr/lib64/dia/libdia.so
 *   found /usr/lib64/dia/libdxf_filter.so
 *   found /usr/lib64/dia/liber_objects.so
 *   found /usr/lib64/dia/libflowchart_objects.so
 *   found /usr/lib64/dia/libfs_objects.so
 *   found /usr/lib64/dia/libgrafcet_objects.so
 *   found /usr/lib64/dia/libhpgl_filter.so
 *   found /usr/lib64/dia/libistar_objects.so
 *   found /usr/lib64/dia/libjackson_objects.so
 *   found /usr/lib64/dia/libkaos_objects.so
 *   found /usr/lib64/dia/libmetapost_filter.so
 *   found /usr/lib64/dia/libmisc_objects.so
 *   found /usr/lib64/dia/libnetwork_objects.so
 *   found /usr/lib64/dia/libpgf_filter.so
 *   found /usr/lib64/dia/libpixbuf_filter.so
 *   found /usr/lib64/dia/libpostscript_filter.so
 *   found /usr/lib64/dia/libpstricks_filter.so
 *   found /usr/lib64/dia/libpython_plugin.so
^C *   ...terminated. Removing incomplete 3_broken.rr 3_errors.rr.

Re: [gentoo-user] Re: Updating libpng: another libtool cockup?

[Michael Schreckenbauer]

On Monday, 19. September 2011 10:20:25 Allan Gottlieb wrote:
> On Mon, Sep 19 2011, Alan McKinnon wrote:
> >> > revdep-rebuild checks everything, revdep-rebuild --library
> >> > checks just some things.
> >> > 
> >> > ebuilds sometimes issue messages to check just the libraries known
> >> > to have been updated, but a full revdep-rebuild after an update
> >> > will catch those anyway.
> >> 
> >> Until recently I skipped the "--library" step exactly because I knew
> >> revdep-rebuild will find and fix the broken packages after I delete
> >> the old library.  So, why bother with the --library step, right?
> >> 
> >> However.  A few weeks ago I got caught when I deleted one of those
> >> obsolete libraries and only then did I find out that gcc is one of
> >> the packages that depend on it :(
> >> 
> >> I don't skip the --library step any more.
> > 
> > That's odd behaviour, I wonder what caused the difference.
> > 
> > Surely revdep-rebuild itself can't do this different just because you
> > specified a library to compare? I wonder if that lib was maybe in the
> > revdep-rebuild exclude list.
> > 
> > I'd be interested to track it down for reference, do you remember the
> > library involved?
> 
> It occurs exactly in the case we are discussing libpng
> 
> ajglap gottlieb # revdep-rebuild; revdep-rebuild --library
> '/usr/lib64/libpng14.so.14' * Configuring search environment for
> revdep-rebuild
> 
>  * Checking reverse dependencies
>  * Packages containing binaries and libraries broken by a package update
>  * will be emerged.
> ...
>  * Checking reverse dependencies
>  * Packages containing binaries and libraries using
> /usr/lib64/libpng14.so.14 * will be emerged.

First one emerges *broken* packages.
Second one emerge packages *using* png14 (not necessarily broken)

Best,
Michael

Re: [gentoo-user] Re: Updating libpng: another libtool cockup?

[Michael Mol]

On Mon, Sep 19, 2011 at 10:20 AM, Allan Gottlieb <gottlieb@nyu.edu> wrote:
> On Mon, Sep 19 2011, Alan McKinnon wrote:
>>> > revdep-rebuild checks everything, revdep-rebuild --library
>>> > checks just some things.
>>> >
>>> > ebuilds sometimes issue messages to check just the libraries known
>>> > to have been updated, but a full revdep-rebuild after an update
>>> > will catch those anyway.
>>>
>>> Until recently I skipped the "--library" step exactly because I knew
>>> revdep-rebuild will find and fix the broken packages after I delete
>>> the old library.  So, why bother with the --library step, right?
>>>
>>> However.  A few weeks ago I got caught when I deleted one of those
>>> obsolete libraries and only then did I find out that gcc is one of
>>> the packages that depend on it :(
>>>
>>> I don't skip the --library step any more.
>>
>> That's odd behaviour, I wonder what caused the difference.
>>
>> Surely revdep-rebuild itself can't do this different just because you
>> specified a library to compare? I wonder if that lib was maybe in the
>> revdep-rebuild exclude list.
>>
>> I'd be interested to track it down for reference, do you remember the
>> library involved?
>
> It occurs exactly in the case we are discussing libpng
>
> ajglap gottlieb # revdep-rebuild; revdep-rebuild --library '/usr/lib64/libpng14.so.14'
>  * Configuring search environment for revdep-rebuild
>
>  * Checking reverse dependencies
>  * Packages containing binaries and libraries broken by a package update
>  * will be emerged.
>
>  * Collecting system binaries and libraries
>  * Generated new 1_files.rr
>  * Collecting complete LD_LIBRARY_PATH
>  * Generated new 2_ldpath.rr
>  * Checking dynamic linking consistency
> [ 100% ]
>
>  * Dynamic linking on your system is consistent... All done.
>  * Configuring search environment for revdep-rebuild
>
>  * Checking reverse dependencies
>  * Packages containing binaries and libraries using /usr/lib64/libpng14.so.14
>  * will be emerged.
>
>  * Collecting system binaries and libraries
>  * Generated new 1_files.rr
>  * Checking dynamic linking
> [ 8% ]  *   found /usr/bin/dia
> [ 46% ]  *   found /usr/lib64/dia/libaadl_objects.so
>  *   found /usr/lib64/dia/libart_filter.so
>  *   found /usr/lib64/dia/libcairo_filter.so
>  *   found /usr/lib64/dia/libcgm_filter.so
>  *   found /usr/lib64/dia/libchronogram_objects.so
>  *   found /usr/lib64/dia/libcustom_lines_objects.so
>  *   found /usr/lib64/dia/libcustom_objects.so
>  *   found /usr/lib64/dia/libdb_objects.so
>  *   found /usr/lib64/dia/libdia.so
>  *   found /usr/lib64/dia/libdxf_filter.so
>  *   found /usr/lib64/dia/liber_objects.so
>  *   found /usr/lib64/dia/libflowchart_objects.so
>  *   found /usr/lib64/dia/libfs_objects.so
>  *   found /usr/lib64/dia/libgrafcet_objects.so
>  *   found /usr/lib64/dia/libhpgl_filter.so
>  *   found /usr/lib64/dia/libistar_objects.so
>  *   found /usr/lib64/dia/libjackson_objects.so
>  *   found /usr/lib64/dia/libkaos_objects.so
>  *   found /usr/lib64/dia/libmetapost_filter.so
>  *   found /usr/lib64/dia/libmisc_objects.so
>  *   found /usr/lib64/dia/libnetwork_objects.so
>  *   found /usr/lib64/dia/libpgf_filter.so
>  *   found /usr/lib64/dia/libpixbuf_filter.so
>  *   found /usr/lib64/dia/libpostscript_filter.so
>  *   found /usr/lib64/dia/libpstricks_filter.so
>  *   found /usr/lib64/dia/libpython_plugin.so
> ^C *   ...terminated. Removing incomplete 3_broken.rr 3_errors.rr.

Is there no automated way to catch these? --library expects an
argument; how do I know which libraries to feed it?

-- 
:wq

Re: [gentoo-user] Re: Updating libpng: another lib tool cockup?

[Allan Gottlieb]

On Mon, Sep 19 2011, Michael Schreckenbauer wrote:

> On Monday, 19. September 2011 10:20:25 Allan Gottlieb wrote:
>> On Mon, Sep 19 2011, Alan McKinnon wrote:
>> >> > revdep-rebuild checks everything, revdep-rebuild --library
>> >> > checks just some things.
>> >> > 
>> >> > ebuilds sometimes issue messages to check just the libraries known
>> >> > to have been updated, but a full revdep-rebuild after an update
>> >> > will catch those anyway.
>> >> 
>> >> Until recently I skipped the "--library" step exactly because I knew
>> >> revdep-rebuild will find and fix the broken packages after I delete
>> >> the old library.  So, why bother with the --library step, right?
>> >> 
>> >> However.  A few weeks ago I got caught when I deleted one of those
>> >> obsolete libraries and only then did I find out that gcc is one of
>> >> the packages that depend on it :(
>> >> 
>> >> I don't skip the --library step any more.
>> > 
>> > That's odd behaviour, I wonder what caused the difference.
>> > 
>> > Surely revdep-rebuild itself can't do this different just because you
>> > specified a library to compare? I wonder if that lib was maybe in the
>> > revdep-rebuild exclude list.
>> > 
>> > I'd be interested to track it down for reference, do you remember the
>> > library involved?
>> 
>> It occurs exactly in the case we are discussing libpng
>> 
>> ajglap gottlieb # revdep-rebuild; revdep-rebuild --library
>> '/usr/lib64/libpng14.so.14' * Configuring search environment for
>> revdep-rebuild
>> 
>>  * Checking reverse dependencies
>>  * Packages containing binaries and libraries broken by a package update
>>  * will be emerged.
>> ...
>>  * Checking reverse dependencies
>>  * Packages containing binaries and libraries using
>> /usr/lib64/libpng14.so.14 * will be emerged.
>
> First one emerges *broken* packages.
> Second one emerge packages *using* png14 (not necessarily broken)

OK.  But the claim was that: if
   revdep-rebuild
with no argument found nothing to build, then
   revdep-rebuild --library <some-library>
will find nothing.

This guarantee is apparently no long true as my example in another msg
illustrated.

allan

[gentoo-user] Re: Updating libpng: another libtool cockup?

[walt]

On 09/19/2011 07:10 AM, Alan McKinnon wrote:
> On Mon, 19 Sep 2011 03:06:30 -0700
> walt <w41ter@gmail.com> wrote:
> 
>> On Mon, 2011-09-19 at 01:39 +0200, Alan McKinnon wrote:
>>> On Sun, 18 Sep 2011 17:58:14 -0400
>>> Allan Gottlieb <gottlieb@nyu.edu> wrote:
>>>
>>>> On Sun, Sep 18 2011, walt wrote:
>>>>
>>>>> I just did a routine update on my ~amd64 machine and saw the
>>>>> portage warning that libpng14 has been replaced by libpng15,
>>>>> and I should run revdep-rebuild --library
>>>>> '/usr/lib/libpng14.so' and then delete the obsolete library.
>>>>>
>>>>> After that I ran plain revdep-rebuild as I do after every
>>>>> update, and saw that two gnome packages failed to rebuild
>>>>> properly because lpng14 couldn't be found :/
>>>>>
>>>>> From painful experience I've learned that good-old libtool files
>>>>> (*.la) are the usual suspects, and grep found -lpng14 in about
>>>>> ten .la files even after both revdep-rebuilds.  Grrr!
>>>>>
>>>>> This fixed the problem for me (as similar moves have done in the
>>>>> past):
>>>>>
>>>>> #find /usr/lib64 -name \*.la -exec sed -i s/png14/png15/ '{}'
>>>>> ';'
>>>>
>>>> Thanks for the tip.  I wonder when a routing update world tells
>>>> you to run
>>>>    revdep-rebuild --library <some-lib>
>>>> should you run it before or after the normal
>>>>    revdep-rebuild
>>>> that we normally run after updates?
>>>
>>> Neither. 
>>>
>>> revdep-rebuild checks everything, revdep-rebuild --library
>>> checks just some things.
>>>
>>> ebuilds sometimes issue messages to check just the libraries known
>>> to have been updated, but a full revdep-rebuild after an update
>>> will catch those anyway.
>>
>> Until recently I skipped the "--library" step exactly because I knew
>> revdep-rebuild will find and fix the broken packages after I delete
>> the old library.  So, why bother with the --library step, right?
>>
>> However.  A few weeks ago I got caught when I deleted one of those
>> obsolete libraries and only then did I find out that gcc is one of
>> the packages that depend on it :(
>>
>> I don't skip the --library step any more.
> 
> That's odd behaviour, I wonder what caused the difference.
> 
> Surely revdep-rebuild itself can't do this different just because you
> specified a library to compare? I wonder if that lib was maybe in the
> revdep-rebuild exclude list.
> 
> I'd be interested to track it down for reference, do you remember the
> library involved?

I think it may have been one of the libs pulled in by the graphite
useflag, like ppl or cloog-ppl, but I can't recall the details.  I
imagine most people wouldn't be affected because most people don't
set that flag, I'd guess.

Remember, I updated the system and deleted the obsolete lib *before*
I ran revdep-rebuild -- and then revdep-rebuild failed because gcc
couldn't build *anything* after that.  I should have moved the lib
to /tmp instead of deleting it.  Recovery would have been trivial.

Re: [gentoo-user] Re: Updating libpng: another lib tool cockup?

[Michael Schreckenbauer]

On Monday, 19. September 2011 10:58:52 Allan Gottlieb wrote:
> On Mon, Sep 19 2011, Michael Schreckenbauer wrote:
> > On Monday, 19. September 2011 10:20:25 Allan Gottlieb wrote:
> >> On Mon, Sep 19 2011, Alan McKinnon wrote:
> >> >> > revdep-rebuild checks everything, revdep-rebuild --library
> >> >> > checks just some things.
> >> >> > 
> >> >> > ebuilds sometimes issue messages to check just the libraries
> >> >> > known
> >> >> > to have been updated, but a full revdep-rebuild after an
> >> >> > update
> >> >> > will catch those anyway.
> >> >> 
> >> >> Until recently I skipped the "--library" step exactly because I
> >> >> knew
> >> >> revdep-rebuild will find and fix the broken packages after I
> >> >> delete
> >> >> the old library.  So, why bother with the --library step, right?
> >> >> 
> >> >> However.  A few weeks ago I got caught when I deleted one of
> >> >> those
> >> >> obsolete libraries and only then did I find out that gcc is one
> >> >> of
> >> >> the packages that depend on it :(
> >> >> 
> >> >> I don't skip the --library step any more.
> >> > 
> >> > That's odd behaviour, I wonder what caused the difference.
> >> > 
> >> > Surely revdep-rebuild itself can't do this different just because
> >> > you
> >> > specified a library to compare? I wonder if that lib was maybe in
> >> > the
> >> > revdep-rebuild exclude list.
> >> > 
> >> > I'd be interested to track it down for reference, do you remember
> >> > the
> >> > library involved?
> >> 
> >> It occurs exactly in the case we are discussing libpng
> >> 
> >> ajglap gottlieb # revdep-rebuild; revdep-rebuild --library
> >> '/usr/lib64/libpng14.so.14' * Configuring search environment for
> >> revdep-rebuild
> >> 
> >>  * Checking reverse dependencies
> >>  * Packages containing binaries and libraries broken by a package
> >>  update
> >>  * will be emerged.
> >> 
> >> ...
> >> 
> >>  * Checking reverse dependencies
> >>  * Packages containing binaries and libraries using
> >> 
> >> /usr/lib64/libpng14.so.14 * will be emerged.
> > 
> > First one emerges *broken* packages.
> > Second one emerge packages *using* png14 (not necessarily broken)
> 
> OK.  But the claim was that: if
>    revdep-rebuild
> with no argument found nothing to build, then
>    revdep-rebuild --library <some-library>
> will find nothing.

This is not true.
revdep-rebuild without --library argument checks for packages with *broken* 
linking, eg a library changed it's name and the original one was removed by an 
update.
revdep-rebuild --library checks for packages using that library.

If the first one returns nothing, that means, your linking is all ok.
If the second one returns nothing, it tells you, that nothing is using that 
library at all.

> This guarantee is apparently no long true as my example in another msg
> illustrated.

I doubt it was true in the past.

Best,
Michael

Re: [gentoo-user] Re: Updating libpng: another lib tool cockup?

[Alan McKinnon]

On Mon, 19 Sep 2011 10:58:52 -0400
Allan Gottlieb <gottlieb@nyu.edu> wrote:

> > First one emerges *broken* packages.
> > Second one emerge packages *using* png14 (not necessarily broken)  
> 
> OK.  But the claim was that: if
>    revdep-rebuild
> with no argument found nothing to build, then
>    revdep-rebuild --library <some-library>
> will find nothing.
> 
> This guarantee is apparently no long true as my example in another msg
> illustrated.

Michael is indeed correct.

A careful reading of the man page reveals the usage of the words
"broken" and "using" exactly like he said. So I stand humbly corrected.

I find revdep-rebuild's behavior in this respect confusing. Even though
it is clearly documented it is unexpected. It would never have occurred
to me to draw that distinction.

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Updating libpng: another lib tool cockup?

[Michael Schreckenbauer]

On Monday, 19. September 2011 17:28:26 Alan McKinnon wrote:
> On Mon, 19 Sep 2011 10:58:52 -0400
> 
> Allan Gottlieb <gottlieb@nyu.edu> wrote:
> > > First one emerges *broken* packages.
> > > Second one emerge packages *using* png14 (not necessarily broken)
> > 
> > OK.  But the claim was that: if
> > 
> >    revdep-rebuild
> > 
> > with no argument found nothing to build, then
> > 
> >    revdep-rebuild --library <some-library>
> > 
> > will find nothing.
> > 
> > This guarantee is apparently no long true as my example in another msg
> > illustrated.
> 
> Michael is indeed correct.
> 
> A careful reading of the man page reveals the usage of the words
> "broken" and "using" exactly like he said. So I stand humbly corrected.
> 
> I find revdep-rebuild's behavior in this respect confusing. Even though
> it is clearly documented it is unexpected. It would never have occurred
> to me to draw that distinction.

I think, it is very useful.

An example:
$ ldd /bin/bash                                                                                                                                
        linux-vdso.so.1 =>  (0x00007fffbafff000)                                                                                                                              
        libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f0a4c278000)                                                                                                        
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f0a4c074000)                                                                                                                  
        libc.so.6 => /lib64/libc.so.6 (0x00007f0a4bce4000)                                                                                                                    
        /lib64/ld-linux-x86-64.so.2 (0x00007f0a4c4ce000)

Assume ncurses get's an update (new version is libncurses.so.6)
Now if portage decided to *remove* libncurses.so.5 during that update, my bash 
would be broken. Very bad, so the ebuild-writer decides to leave 
libncurses.so.5 on my system.
Because linking of bash is consistent (it still links to .so.5) a run of 
revdep-rebuild without args would return without result.
With revdep-rebuild --library libncurses.so.5 I am now able to find and rebuild 
all packages, that use the "ancient" version of ncurses and after that, I can 
*safely* remove it.

Best,
Michael

Re: [gentoo-user] Re: Updating libpng: another lib tool cockup?

[Paul Hartman]

On Mon, Sep 19, 2011 at 9:58 AM, Allan Gottlieb <gottlieb@nyu.edu> wrote:
> OK.  But the claim was that: if
>   revdep-rebuild
> with no argument found nothing to build, then
>   revdep-rebuild --library <some-library>
> will find nothing.

I think what everyone (except Michael S) seems to be confused about is:

Normal revdep-rebuild (with no options) looks for broken shared
library dependencies and rebuilds them. If you run it again, it won't
rebuild anything, because the dependency has been fixed.

Using the --library switch, however, it looks for everything built
against that library, regardless of whether or not the dependency is
broken, and rebuilds it. If you run this command 10 times in a row
it'll rebuild the same libraries 10 times.

Presumably, there are cases (like libpng) when it is desirable to
rebuild dependencies but they aren't "broken" in the way that
revdep-rebuild normally can detect. So using --library will
brute-force rebuild everything that depends on that library, just to
make sure they are built against the new version.

Moral of the story; if an ebuild tells you to revdep-rebuild
--library, do it. :)

Re: [gentoo-user] Re: Updating libpng: another libtool cockup?

[David W Noon]

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

On Mon, 19 Sep 2011 16:10:02 +0200, Alan McKinnon wrote about Re:
[gentoo-user] Re: Updating libpng:  another libtool cockup?:

> On Mon, 19 Sep 2011 03:06:30 -0700
> walt <w41ter@gmail.com> wrote:
[snip]
> > I don't skip the --library step any more.
> 
> That's odd behaviour, I wonder what caused the difference.

I guess your graph theory is out to lunch today. ... :-)

The problem is portage determining the dependency graph, but ebuilds do
not contain enough information to do this thoroughly.  The best
example, at least in my memory, was the libexpat upgrade about 4 years
ago that trashed everybody's system -- many resorted to complete
re-installation.

At the end of that upgrade, there was an instruction to preform a
revdep-rebuild specifically for libexpat.so.  Now, this upgrade
coincided with a full upgrade to KDE plus a full upgrade to GNOME, all
on the same day.  As a result, the message to do a revdep-rebuild
specifically on libexpat was buried in other bumpf, plus there was other
library breakage out the yin-yang -- an extremely large yin-yang.  It
was a sysadmin's perfect storm.

Doing a simple revdep-rebuild, with no library constraint, caused
ebuild breakage by the mile.  This was because the subroutines in
libexpat are used inside ebuild processing by documentation utilities
such as ghostscript, xsltproc, etc.

OTOH, if one did a specific revdep-rebuild on libexpat, all of those
documentation utilities would be rebuilt before the main
revdep-rebuild.  After that, the ebuilds all went smoothly.

Unfortunately, Portage does not have enough information to infer these
deep dependencies.  This means it cannot schedule the more fundamental
revdep-rebuild ahead of those that depend upon it.  We have to do that
by hand.

I hope this has explained why we should take messages about running
"revdep-rebuild --library libXXX" seriously.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Updating libpng: another lib tool cockup?

[covici]

Allan Gottlieb <gottlieb@nyu.edu> wrote:

> On Mon, Sep 19 2011, Michael Schreckenbauer wrote:
> 
> > On Monday, 19. September 2011 10:20:25 Allan Gottlieb wrote:
> >> On Mon, Sep 19 2011, Alan McKinnon wrote:
> >> >> > revdep-rebuild checks everything, revdep-rebuild --library
> >> >> > checks just some things.
> >> >> > 
> >> >> > ebuilds sometimes issue messages to check just the libraries known
> >> >> > to have been updated, but a full revdep-rebuild after an update
> >> >> > will catch those anyway.
> >> >> 
> >> >> Until recently I skipped the "--library" step exactly because I knew
> >> >> revdep-rebuild will find and fix the broken packages after I delete
> >> >> the old library.  So, why bother with the --library step, right?
> >> >> 
> >> >> However.  A few weeks ago I got caught when I deleted one of those
> >> >> obsolete libraries and only then did I find out that gcc is one of
> >> >> the packages that depend on it :(
> >> >> 
> >> >> I don't skip the --library step any more.
> >> > 
> >> > That's odd behaviour, I wonder what caused the difference.
> >> > 
> >> > Surely revdep-rebuild itself can't do this different just because you
> >> > specified a library to compare? I wonder if that lib was maybe in the
> >> > revdep-rebuild exclude list.
> >> > 
> >> > I'd be interested to track it down for reference, do you remember the
> >> > library involved?
> >> 
> >> It occurs exactly in the case we are discussing libpng
> >> 
> >> ajglap gottlieb # revdep-rebuild; revdep-rebuild --library
> >> '/usr/lib64/libpng14.so.14' * Configuring search environment for
> >> revdep-rebuild
> >> 
> >>  * Checking reverse dependencies
> >>  * Packages containing binaries and libraries broken by a package update
> >>  * will be emerged.
> >> ...
> >>  * Checking reverse dependencies
> >>  * Packages containing binaries and libraries using
> >> /usr/lib64/libpng14.so.14 * will be emerged.
> >
> > First one emerges *broken* packages.
> > Second one emerge packages *using* png14 (not necessarily broken)
> 
> OK.  But the claim was that: if
>    revdep-rebuild
> with no argument found nothing to build, then
>    revdep-rebuild --library <some-library>
> will find nothing.
> 
> This guarantee is apparently no long true as my example in another msg
> illustrated.
Will emerge @preserved-rebuild catch the second case here?


-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: [gentoo-user] Re: Updating libpng: another lib tool cockup?

[Allan Gottlieb]

On Mon, Sep 19 2011, Paul Hartman wrote:

> On Mon, Sep 19, 2011 at 9:58 AM, Allan Gottlieb <gottlieb@nyu.edu> wrote:
>> OK.  But the claim was that: if
>>   revdep-rebuild
>> with no argument found nothing to build, then
>>   revdep-rebuild --library <some-library>
>> will find nothing.
>
> I think what everyone (except Michael S) seems to be confused about is:
>
> Normal revdep-rebuild (with no options) looks for broken shared
> library dependencies and rebuilds them. If you run it again, it won't
> rebuild anything, because the dependency has been fixed.
>
> Using the --library switch, however, it looks for everything built
> against that library, regardless of whether or not the dependency is
> broken, and rebuilds it. If you run this command 10 times in a row
> it'll rebuild the same libraries 10 times.
>
> Presumably, there are cases (like libpng) when it is desirable to
> rebuild dependencies but they aren't "broken" in the way that
> revdep-rebuild normally can detect. So using --library will
> brute-force rebuild everything that depends on that library, just to
> make sure they are built against the new version.
>
> Moral of the story; if an ebuild tells you to revdep-rebuild
> --library, do it. :)

Thanks for the clarification.

When revdep-rebuild --library is suggested should we run it
before or after the ordinary revdep-rebuild that we typically
run after each update world?
(That was actually my original question :-)

thanks,
allan

Re: [gentoo-user] Re: Updating libpng: another lib tool cockup?

[Paul Hartman]

On Mon, Sep 19, 2011 at 12:57 PM, Allan Gottlieb <gottlieb@nyu.edu> wrote:
> When revdep-rebuild --library is suggested should we run it
> before or after the ordinary revdep-rebuild that we typically
> run after each update world?

I think you should run it with --library first. There exists the
possiblity that --library will rebuild something that a normal
revdep-rebuild would have also wanted to rebuild, so running --library
first could potentially save you from repeat rebuilding.

Re: [gentoo-user] Re: Updating libpng: another lib tool cockup?

[Allan Gottlieb]

On Mon, Sep 19 2011, Paul Hartman wrote:

> On Mon, Sep 19, 2011 at 12:57 PM, Allan Gottlieb <gottlieb@nyu.edu> wrote:
>> When revdep-rebuild --library is suggested should we run it
>> before or after the ordinary revdep-rebuild that we typically
>> run after each update world?
>
> I think you should run it with --library first. There exists the
> possiblity that --library will rebuild something that a normal
> revdep-rebuild would have also wanted to rebuild, so running --library
> first could potentially save you from repeat rebuilding.

thanks,
allan

Re: [gentoo-user] Re: Updating libpng: another libtool cockup?

[Mark Knecht]

On Mon, Sep 19, 2011 at 7:36 AM, Michael Mol <mikemol@gmail.com> wrote:
> On Mon, Sep 19, 2011 at 10:20 AM, Allan Gottlieb <gottlieb@nyu.edu> wrote:
<SNIP>
>> ajglap gottlieb # revdep-rebuild; revdep-rebuild --library '/usr/lib64/libpng14.so.14'
<SNIP>
>
> Is there no automated way to catch these? --library expects an
> argument; how do I know which libraries to feed it?
>
> --
> :wq

My question exactly. It's not likeyou can look at just names of
libraries as I think to do this right you've got to look at every
revision of every library on the system, don't you?

It's possible that this problem could exist for a long while if a
program doesn't get used much...

- Mark

Re: [gentoo-user] Re: Updating libpng: another libtool cockup?

[Michael Mol]

On Mon, Sep 19, 2011 at 4:33 PM, Mark Knecht <markknecht@gmail.com> wrote:
> On Mon, Sep 19, 2011 at 7:36 AM, Michael Mol <mikemol@gmail.com> wrote:
>> On Mon, Sep 19, 2011 at 10:20 AM, Allan Gottlieb <gottlieb@nyu.edu> wrote:
> <SNIP>
>>> ajglap gottlieb # revdep-rebuild; revdep-rebuild --library '/usr/lib64/libpng14.so.14'
> <SNIP>
>>
>> Is there no automated way to catch these? --library expects an
>> argument; how do I know which libraries to feed it?
>
> My question exactly. It's not likeyou can look at just names of
> libraries as I think to do this right you've got to look at every
> revision of every library on the system, don't you?
>
> It's possible that this problem could exist for a long while if a
> program doesn't get used much...

Based on subsequent discussion since I wrote that question, I think
the answer is, "currently, no." Ebuillds would need more metadata, and
portage would need to be more aware of deep dependencies.

I'm not sure of revdep-rebuild's angle, or how it might be able to be
improved to detect errors that don't come from broken linkage.
-- 
:wq

Re: [gentoo-user] Re: Updating libpng: another libtool cockup?

[Mark Knecht]

On Mon, Sep 19, 2011 at 1:41 PM, Michael Mol <mikemol@gmail.com> wrote:
> On Mon, Sep 19, 2011 at 4:33 PM, Mark Knecht <markknecht@gmail.com> wrote:
>> On Mon, Sep 19, 2011 at 7:36 AM, Michael Mol <mikemol@gmail.com> wrote:
>>> On Mon, Sep 19, 2011 at 10:20 AM, Allan Gottlieb <gottlieb@nyu.edu> wrote:
>> <SNIP>
>>>> ajglap gottlieb # revdep-rebuild; revdep-rebuild --library '/usr/lib64/libpng14.so.14'
>> <SNIP>
>>>
>>> Is there no automated way to catch these? --library expects an
>>> argument; how do I know which libraries to feed it?
>>
>> My question exactly. It's not likeyou can look at just names of
>> libraries as I think to do this right you've got to look at every
>> revision of every library on the system, don't you?
>>
>> It's possible that this problem could exist for a long while if a
>> program doesn't get used much...
>
> Based on subsequent discussion since I wrote that question, I think
> the answer is, "currently, no." Ebuillds would need more metadata, and
> portage would need to be more aware of deep dependencies.
>
> I'm not sure of revdep-rebuild's angle, or how it might be able to be
> improved to detect errors that don't come from broken linkage.
> --
> :wq

OK, I saw that comment but didn't grasp that it's the answer. Could be.

Alternatively, in Michael's example earlier, I don't think the ldd
results for bash are changed (are they?) when ncurses is updated:

[QUOTE]
$ ldd /bin/bash
       linux-vdso.so.1 =>  (0x00007fffbafff000)
       libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f0a4c278000)
       libdl.so.2 => /lib64/libdl.so.2 (0x00007f0a4c074000)
       libc.so.6 => /lib64/libc.so.6 (0x00007f0a4bce4000)
       /lib64/ld-linux-x86-64.so.2 (0x00007f0a4c4ce000)
[/QUOTE]

It seems to me this is tending toward something similar to slots,
isn't it? If one package (bash) needs a specific version then can't we
find it using ldd (on every package on the system unfortunately) and
ensure that the needed .so files aren't removed?

/lib64/libncurses.so.5 & /lib64/libncurses.so.6 could both exist on
the system even if both version of the ncurses package don't.

I suspect this is mostly what revdep-rebuild is already doing, and I
also suspect my view of the problem is far too remedial...

Thanks,
Mark

Re: [gentoo-user] Re: Updating libpng: another libtool cockup?

[Peter Humphrey]

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

On Monday 19 September 2011 16:49:55 David W Noon wrote:

> I hope this has explained why we should take messages about running
> "revdep-rebuild --library libXXX" seriously.

Well, you have me convinced. I had assumed that a bland revdep-rebuild would 
catch everything including the library specified. Wrong, I see.

-- 
Rgds
Peter		Linux Counter 5290, 1994-04-23

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

[gentoo-user] Re: Updating libpng: another libtool cockup?

[Nikos Chantziaras]

On 09/18/2011 11:10 PM, walt wrote:
> I just did a routine update on my ~amd64 machine and saw the portage
> warning that libpng14 has been replaced by libpng15, and I should run
> revdep-rebuild --library '/usr/lib/libpng14.so' and then delete the
> obsolete library.

Oh crap.  I somehow missed that (and I try to always read the logs with 
'elog').  But this somehow skipped past my radar.  I still have 
libpng14.so in /usr/lib.  revdep-rebuild lists about 80 packages needing 
a rebuild.

Is there a way to check the system whether old libraries are still around?

Re: [gentoo-user] Re: Updating libpng: another libtool cockup?

[Michael Schreckenbauer]

On Monday, 19. September 2011 13:52:26 Mark Knecht wrote:
> On Mon, Sep 19, 2011 at 1:41 PM, Michael Mol <mikemol@gmail.com> wrote:
> > On Mon, Sep 19, 2011 at 4:33 PM, Mark Knecht <markknecht@gmail.com> wrote:
> >> On Mon, Sep 19, 2011 at 7:36 AM, Michael Mol <mikemol@gmail.com> wrote:
> >>> On Mon, Sep 19, 2011 at 10:20 AM, Allan Gottlieb <gottlieb@nyu.edu> 
wrote:
> >> <SNIP>
> >> 
> >>>> ajglap gottlieb # revdep-rebuild; revdep-rebuild --library
> >>>> '/usr/lib64/libpng14.so.14'>> 
> >> <SNIP>
> >> 
> >>> Is there no automated way to catch these? --library expects an
> >>> argument; how do I know which libraries to feed it?
> >> 
> >> My question exactly. It's not likeyou can look at just names of
> >> libraries as I think to do this right you've got to look at every
> >> revision of every library on the system, don't you?
> >> 
> >> It's possible that this problem could exist for a long while if a
> >> program doesn't get used much...
> > 
> > Based on subsequent discussion since I wrote that question, I think
> > the answer is, "currently, no." Ebuillds would need more metadata, and
> > portage would need to be more aware of deep dependencies.
> > 
> > I'm not sure of revdep-rebuild's angle, or how it might be able to be
> > improved to detect errors that don't come from broken linkage.
> > --
> > 
> > :wq
> 
> OK, I saw that comment but didn't grasp that it's the answer. Could be.
> 
> Alternatively, in Michael's example earlier, I don't think the ldd
> results for bash are changed (are they?) when ncurses is updated:
> 
> [QUOTE]
> $ ldd /bin/bash
>        linux-vdso.so.1 =>  (0x00007fffbafff000)
>        libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f0a4c278000)
>        libdl.so.2 => /lib64/libdl.so.2 (0x00007f0a4c074000)
>        libc.so.6 => /lib64/libc.so.6 (0x00007f0a4bce4000)
>        /lib64/ld-linux-x86-64.so.2 (0x00007f0a4c4ce000)
> [/QUOTE]

They would change to

$ ldd /bin/bash
        linux-vdso.so.1 =>  (0x00007fffbafff000)
        libncurses.so.5 => not found
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f0a4c074000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f0a4bce4000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f0a4c4ce000)

if the ebuild maintainer forgets to keep the *.so.5 version on the system in 
the *.so.6 update. That results in a broken bash.

> It seems to me this is tending toward something similar to slots,
> isn't it? If one package (bash) needs a specific version then can't we
> find it using ldd (on every package on the system unfortunately) and
> ensure that the needed .so files aren't removed?

That's what ebuild maintainers do, afaik.

~ $ equery b /usr/lib64/libpng14.so.14
 * Searching for /usr/lib64/libpng14.so.14 ... 
media-libs/libpng-1.5.4 (/usr/lib64/libpng14.so.14)

See? libpng14 is part of png-1.5.x package, so libpng14 is not removed, when 
you install the 1.5.x version. That keeps programs going.

> /lib64/libncurses.so.5 & /lib64/libncurses.so.6 could both exist on
> the system even if both version of the ncurses package don't.

That's right. But keep in mind, that the old lib is outdated. Bugs remain 
bugs, nothing is fixed. Getting fixes, is why we update after all, isn't it?

> I suspect this is mostly what revdep-rebuild is already doing, and I
> also suspect my view of the problem is far too remedial...
> 
> Thanks,
> Mark

Best,
Michael

Re: [gentoo-user] Re: Updating libpng: another libtool cockup?

[Mark Knecht]

On Mon, Sep 19, 2011 at 2:10 PM, Michael Schreckenbauer <grimlog@gmx.de> wrote:
> On Monday, 19. September 2011 13:52:26 Mark Knecht wrote:
<SNIP>
>
>> /lib64/libncurses.so.5 & /lib64/libncurses.so.6 could both exist on
>> the system even if both version of the ncurses package don't.
>
> That's right. But keep in mind, that the old lib is outdated. Bugs remain
> bugs, nothing is fixed. Getting fixes, is why we update after all, isn't it?
>

Right, but better that I have a bug until the next update that fixes
this than a system that doesn't work because bash crashes, right?

I was only thinking very short term and not that the ebuild maintainer
shouldn't eventually get things right with all bug fixes.

Thanks for getting this issue out there today. It's been very helpful
to have you along!

Cheers,
Mark

Re: [gentoo-user] Re: Updating libpng: another libtool cockup?

[covici]

Peter Humphrey <peter@humphrey.ukfsn.org> wrote:

> On Monday 19 September 2011 16:49:55 David W Noon wrote:
> 
> > I hope this has explained why we should take messages about running
> > "revdep-rebuild --library libXXX" seriously.
> 
> Well, you have me convinced. I had assumed that a bland revdep-rebuild would 
> catch everything including the library specified. Wrong, I see.
Would  preserved-rebuild catch everything that the revdep-rebuild fails
to catch?


-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: [gentoo-user] Re: Updating libpng: another lib tool cockup?

[Neil Bothwick]

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

On Mon, 19 Sep 2011 13:57:03 -0400, Allan Gottlieb wrote:

> When revdep-rebuild --library is suggested should we run it
> before or after the ordinary revdep-rebuild that we typically
> run after each update world?
> (That was actually my original question :-)

You should run it first, because the elog message is telling you to run
that command, not revdep-rebuild, which is usually unnecessary. The
reason revdep-rebuild alone finds nothing to rebuild is because portage
has ensured that nothing is broken by preserving the old library version.

With a recent enough portage, emerge @preserved-rebuild should avoid the
need for revdep-rebuild entirely, although in this case it doesn't quite
manage that.


-- 
Neil Bothwick

WinErr 004: Erroneous error - Nothing is wrong

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Updating libpng: another libtool cockup?

[Neil Bothwick]

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

On Mon, 19 Sep 2011 18:29:44 -0400, covici@ccs.covici.com wrote:

> > Well, you have me convinced. I had assumed that a bland
> > revdep-rebuild would catch everything including the library
> > specified. Wrong, I see.  
> Would  preserved-rebuild catch everything that the revdep-rebuild fails
> to catch?

In theory yes, in practice it missed a couple of deep dependencies here.


-- 
Neil Bothwick

The law of Probability Dispersal decrees that whatever it is that hits
the fan will not be evenly distributed.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Updating libpng: another lib tool cockup?

[Allan Gottlieb]

On Tue, Sep 20 2011, Neil Bothwick wrote:

> On Mon, 19 Sep 2011 13:57:03 -0400, Allan Gottlieb wrote:
>
>> When revdep-rebuild --library is suggested should we run it
>> before or after the ordinary revdep-rebuild that we typically
>> run after each update world?
>> (That was actually my original question :-)
>
> You should run it first, because the elog message is telling you to run
> that command, not revdep-rebuild, which is usually unnecessary. The
> reason revdep-rebuild alone finds nothing to rebuild is because portage
> has ensured that nothing is broken by preserving the old library version.
>
> With a recent enough portage, emerge @preserved-rebuild should avoid the
> need for revdep-rebuild entirely, although in this case it doesn't quite
> manage that.

Thank you.
allan