| 1 |
On Mon, 19 Sep 2011 03:06:30 -0700 |
| 2 |
walt <w41ter@×××××.com> wrote: |
| 3 |
|
| 4 |
> On Mon, 2011-09-19 at 01:39 +0200, Alan McKinnon wrote: |
| 5 |
> > On Sun, 18 Sep 2011 17:58:14 -0400 |
| 6 |
> > Allan Gottlieb <gottlieb@×××.edu> wrote: |
| 7 |
> > |
| 8 |
> > > On Sun, Sep 18 2011, walt wrote: |
| 9 |
> > > |
| 10 |
> > > > I just did a routine update on my ~amd64 machine and saw the |
| 11 |
> > > > portage warning that libpng14 has been replaced by libpng15, |
| 12 |
> > > > and I should run revdep-rebuild --library |
| 13 |
> > > > '/usr/lib/libpng14.so' and then delete the obsolete library. |
| 14 |
> > > > |
| 15 |
> > > > After that I ran plain revdep-rebuild as I do after every |
| 16 |
> > > > update, and saw that two gnome packages failed to rebuild |
| 17 |
> > > > properly because lpng14 couldn't be found :/ |
| 18 |
> > > > |
| 19 |
> > > > From painful experience I've learned that good-old libtool files |
| 20 |
> > > > (*.la) are the usual suspects, and grep found -lpng14 in about |
| 21 |
> > > > ten .la files even after both revdep-rebuilds. Grrr! |
| 22 |
> > > > |
| 23 |
> > > > This fixed the problem for me (as similar moves have done in the |
| 24 |
> > > > past): |
| 25 |
> > > > |
| 26 |
> > > > #find /usr/lib64 -name \*.la -exec sed -i s/png14/png15/ '{}' |
| 27 |
> > > > ';' |
| 28 |
> > > |
| 29 |
> > > Thanks for the tip. I wonder when a routing update world tells |
| 30 |
> > > you to run |
| 31 |
> > > revdep-rebuild --library <some-lib> |
| 32 |
> > > should you run it before or after the normal |
| 33 |
> > > revdep-rebuild |
| 34 |
> > > that we normally run after updates? |
| 35 |
> > |
| 36 |
> > Neither. |
| 37 |
> > |
| 38 |
> > revdep-rebuild checks everything, revdep-rebuild --library |
| 39 |
> > checks just some things. |
| 40 |
> > |
| 41 |
> > ebuilds sometimes issue messages to check just the libraries known |
| 42 |
> > to have been updated, but a full revdep-rebuild after an update |
| 43 |
> > will catch those anyway. |
| 44 |
> |
| 45 |
> Until recently I skipped the "--library" step exactly because I knew |
| 46 |
> revdep-rebuild will find and fix the broken packages after I delete |
| 47 |
> the old library. So, why bother with the --library step, right? |
| 48 |
> |
| 49 |
> However. A few weeks ago I got caught when I deleted one of those |
| 50 |
> obsolete libraries and only then did I find out that gcc is one of |
| 51 |
> the packages that depend on it :( |
| 52 |
> |
| 53 |
> I don't skip the --library step any more. |
| 54 |
|
| 55 |
That's odd behaviour, I wonder what caused the difference. |
| 56 |
|
| 57 |
Surely revdep-rebuild itself can't do this different just because you |
| 58 |
specified a library to compare? I wonder if that lib was maybe in the |
| 59 |
revdep-rebuild exclude list. |
| 60 |
|
| 61 |
I'd be interested to track it down for reference, do you remember the |
| 62 |
library involved? |
| 63 |
|
| 64 |
|
| 65 |
-- |
| 66 |
Alan McKinnnon |
| 67 |
alan.mckinnon@×××××.com |
Archives