FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 09-19-2011, 02:58 PM
Allan Gottlieb
 
Default Updating libpng: another lib tool cockup?

On Mon, Sep 19 2011, Michael Schreckenbauer wrote:

> 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)

OK. But the claim was that: if
revdep-rebuild
with no argument found nothing to build, then
revdep-rebuild --library <some-library>
will find nothing.

This guarantee is apparently no long true as my example in another msg
illustrated.

allan
 
Old 09-19-2011, 03:19 PM
Michael Schreckenbauer
 
Default Updating libpng: another lib tool cockup?

On Monday, 19. September 2011 10:58:52 Allan Gottlieb wrote:
> On Mon, Sep 19 2011, Michael Schreckenbauer wrote:
> > 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)
>
> OK. But the claim was that: if
> revdep-rebuild
> with no argument found nothing to build, then
> revdep-rebuild --library <some-library>
> will find nothing.

This is not true.
revdep-rebuild without --library argument checks for packages with *broken*
linking, eg a library changed it's name and the original one was removed by an
update.
revdep-rebuild --library checks for packages using that library.

If the first one returns nothing, that means, your linking is all ok.
If the second one returns nothing, it tells you, that nothing is using that
library at all.

> This guarantee is apparently no long true as my example in another msg
> illustrated.

I doubt it was true in the past.

Best,
Michael
 

Thread Tools




All times are GMT. The time now is 06:48 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org