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