public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Allan Gottlieb <gottlieb@nyu.edu>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: Updating libpng:  another lib tool cockup?
Date: Mon, 19 Sep 2011 10:58:52 -0400	[thread overview]
Message-ID: <yu9vcsowpcj.fsf_-_@nyu.edu> (raw)
In-Reply-To: <57242555.Dg011fuPs4@pc> (Michael Schreckenbauer's message of "Mon, 19 Sep 2011 16:34:49 +0200")

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



  reply	other threads:[~2011-09-19 14:59 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-18 20:10 [gentoo-user] Updating libpng: another libtool cockup? walt
2011-09-18 20:48 ` Michael Mol
2011-09-18 20:57 ` Thanasis
2011-09-18 21:54   ` Mick
2011-09-18 21:58 ` Allan Gottlieb
2011-09-18 23:39   ` Alan McKinnon
2011-09-19 10:06     ` [gentoo-user] " walt
2011-09-19 14:10       ` Alan McKinnon
2011-09-19 14:20         ` Allan Gottlieb
2011-09-19 14:34           ` Michael Schreckenbauer
2011-09-19 14:58             ` Allan Gottlieb [this message]
2011-09-19 15:19               ` [gentoo-user] Re: Updating libpng: another lib tool cockup? Michael Schreckenbauer
2011-09-19 15:28               ` Alan McKinnon
2011-09-19 15:49                 ` Michael Schreckenbauer
2011-09-19 15:49               ` Paul Hartman
2011-09-19 17:57                 ` Allan Gottlieb
2011-09-19 18:19                   ` Paul Hartman
2011-09-19 20:08                     ` Allan Gottlieb
2011-09-20 10:38                   ` Neil Bothwick
2011-09-20 12:57                     ` Allan Gottlieb
2011-09-19 16:30               ` covici
2011-09-19 14:36           ` [gentoo-user] Re: Updating libpng: another libtool cockup? Michael Mol
2011-09-19 20:33             ` Mark Knecht
2011-09-19 20:41               ` Michael Mol
2011-09-19 20:52                 ` Mark Knecht
2011-09-19 21:10                   ` Michael Schreckenbauer
2011-09-19 21:28                     ` Mark Knecht
2011-09-19 15:07         ` walt
2011-09-19 15:49         ` David W Noon
2011-09-19 20:54           ` Peter Humphrey
2011-09-19 22:29             ` covici
2011-09-20 10:41               ` Neil Bothwick
2011-09-19 14:06     ` [gentoo-user] " Allan Gottlieb
2011-09-19 21:04 ` [gentoo-user] " Nikos Chantziaras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yu9vcsowpcj.fsf_-_@nyu.edu \
    --to=gottlieb@nyu.edu \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox