public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Michael Schreckenbauer <grimlog@gmx.de>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: Updating libpng:  another lib tool cockup?
Date: Mon, 19 Sep 2011 17:49:19 +0200	[thread overview]
Message-ID: <1415380.sLHfVDNaBR@pc> (raw)
In-Reply-To: <20110919172826.6166664b@rohan.example.com>

On Monday, 19. September 2011 17:28:26 Alan McKinnon wrote:
> On Mon, 19 Sep 2011 10:58:52 -0400
> 
> Allan Gottlieb <gottlieb@nyu.edu> wrote:
> > > 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.
> 
> Michael is indeed correct.
> 
> A careful reading of the man page reveals the usage of the words
> "broken" and "using" exactly like he said. So I stand humbly corrected.
> 
> I find revdep-rebuild's behavior in this respect confusing. Even though
> it is clearly documented it is unexpected. It would never have occurred
> to me to draw that distinction.

I think, it is very useful.

An example:
$ ldd /bin/bash                                                                                                                                
        linux-vdso.so.1 =>  (0x00007fffbafff000)                                                                                                                              
        libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f0a4c278000)                                                                                                        
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f0a4c074000)                                                                                                                  
        libc.so.6 => /lib64/libc.so.6 (0x00007f0a4bce4000)                                                                                                                    
        /lib64/ld-linux-x86-64.so.2 (0x00007f0a4c4ce000)

Assume ncurses get's an update (new version is libncurses.so.6)
Now if portage decided to *remove* libncurses.so.5 during that update, my bash 
would be broken. Very bad, so the ebuild-writer decides to leave 
libncurses.so.5 on my system.
Because linking of bash is consistent (it still links to .so.5) a run of 
revdep-rebuild without args would return without result.
With revdep-rebuild --library libncurses.so.5 I am now able to find and rebuild 
all packages, that use the "ancient" version of ncurses and after that, I can 
*safely* remove it.

Best,
Michael




  reply	other threads:[~2011-09-19 15:50 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             ` [gentoo-user] Re: Updating libpng: another lib tool cockup? Allan Gottlieb
2011-09-19 15:19               ` Michael Schreckenbauer
2011-09-19 15:28               ` Alan McKinnon
2011-09-19 15:49                 ` Michael Schreckenbauer [this message]
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=1415380.sLHfVDNaBR@pc \
    --to=grimlog@gmx.de \
    --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