On 09/19/2011 07:10 AM, Alan McKinnon wrote: > On Mon, 19 Sep 2011 03:06:30 -0700 > walt <[email protected]> wrote: > >> On Mon, 2011-09-19 at 01:39 +0200, Alan McKinnon wrote: >>> On Sun, 18 Sep 2011 17:58:14 -0400 >>> Allan Gottlieb <[email protected]> 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.
