[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@×××.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.