Re: [gentoo-user] Re: Updating libpng: another libtool cockup?

[Michael Schreckenbauer <grimlog@gmx.de>]

On Monday, 19. September 2011 13:52:26 Mark Knecht wrote:
> On Mon, Sep 19, 2011 at 1:41 PM, Michael Mol <mikemol@gmail.com> wrote:
> > On Mon, Sep 19, 2011 at 4:33 PM, Mark Knecht <markknecht@gmail.com> wrote:
> >> On Mon, Sep 19, 2011 at 7:36 AM, Michael Mol <mikemol@gmail.com> wrote:
> >>> On Mon, Sep 19, 2011 at 10:20 AM, Allan Gottlieb <gottlieb@nyu.edu> 
wrote:
> >> <SNIP>
> >> 
> >>>> ajglap gottlieb # revdep-rebuild; revdep-rebuild --library
> >>>> '/usr/lib64/libpng14.so.14'>> 
> >> <SNIP>
> >> 
> >>> Is there no automated way to catch these? --library expects an
> >>> argument; how do I know which libraries to feed it?
> >> 
> >> My question exactly. It's not likeyou can look at just names of
> >> libraries as I think to do this right you've got to look at every
> >> revision of every library on the system, don't you?
> >> 
> >> It's possible that this problem could exist for a long while if a
> >> program doesn't get used much...
> > 
> > Based on subsequent discussion since I wrote that question, I think
> > the answer is, "currently, no." Ebuillds would need more metadata, and
> > portage would need to be more aware of deep dependencies.
> > 
> > I'm not sure of revdep-rebuild's angle, or how it might be able to be
> > improved to detect errors that don't come from broken linkage.
> > --
> > 
> > :wq
> 
> OK, I saw that comment but didn't grasp that it's the answer. Could be.
> 
> Alternatively, in Michael's example earlier, I don't think the ldd
> results for bash are changed (are they?) when ncurses is updated:
> 
> [QUOTE]
> $ 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)
> [/QUOTE]

They would change to

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

if the ebuild maintainer forgets to keep the *.so.5 version on the system in 
the *.so.6 update. That results in a broken bash.

> It seems to me this is tending toward something similar to slots,
> isn't it? If one package (bash) needs a specific version then can't we
> find it using ldd (on every package on the system unfortunately) and
> ensure that the needed .so files aren't removed?

That's what ebuild maintainers do, afaik.

~ $ equery b /usr/lib64/libpng14.so.14
 * Searching for /usr/lib64/libpng14.so.14 ... 
media-libs/libpng-1.5.4 (/usr/lib64/libpng14.so.14)

See? libpng14 is part of png-1.5.x package, so libpng14 is not removed, when 
you install the 1.5.x version. That keeps programs going.

> /lib64/libncurses.so.5 & /lib64/libncurses.so.6 could both exist on
> the system even if both version of the ncurses package don't.

That's right. But keep in mind, that the old lib is outdated. Bugs remain 
bugs, nothing is fixed. Getting fixes, is why we update after all, isn't it?

> I suspect this is mostly what revdep-rebuild is already doing, and I
> also suspect my view of the problem is far too remedial...
> 
> Thanks,
> Mark

Best,
Michael