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
