On Mon, 19 Sep 2011 03:06:30 -0700
walt <w41...@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 <gottl...@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.mckin...@gmail.com
