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