| 1 |
On Monday, 19. September 2011 13:52:26 Mark Knecht wrote: |
| 2 |
> On Mon, Sep 19, 2011 at 1:41 PM, Michael Mol <mikemol@×××××.com> wrote: |
| 3 |
> > On Mon, Sep 19, 2011 at 4:33 PM, Mark Knecht <markknecht@×××××.com> wrote: |
| 4 |
> >> On Mon, Sep 19, 2011 at 7:36 AM, Michael Mol <mikemol@×××××.com> wrote: |
| 5 |
> >>> On Mon, Sep 19, 2011 at 10:20 AM, Allan Gottlieb <gottlieb@×××.edu> |
| 6 |
wrote: |
| 7 |
> >> <SNIP> |
| 8 |
> >> |
| 9 |
> >>>> ajglap gottlieb # revdep-rebuild; revdep-rebuild --library |
| 10 |
> >>>> '/usr/lib64/libpng14.so.14'>> |
| 11 |
> >> <SNIP> |
| 12 |
> >> |
| 13 |
> >>> Is there no automated way to catch these? --library expects an |
| 14 |
> >>> argument; how do I know which libraries to feed it? |
| 15 |
> >> |
| 16 |
> >> My question exactly. It's not likeyou can look at just names of |
| 17 |
> >> libraries as I think to do this right you've got to look at every |
| 18 |
> >> revision of every library on the system, don't you? |
| 19 |
> >> |
| 20 |
> >> It's possible that this problem could exist for a long while if a |
| 21 |
> >> program doesn't get used much... |
| 22 |
> > |
| 23 |
> > Based on subsequent discussion since I wrote that question, I think |
| 24 |
> > the answer is, "currently, no." Ebuillds would need more metadata, and |
| 25 |
> > portage would need to be more aware of deep dependencies. |
| 26 |
> > |
| 27 |
> > I'm not sure of revdep-rebuild's angle, or how it might be able to be |
| 28 |
> > improved to detect errors that don't come from broken linkage. |
| 29 |
> > -- |
| 30 |
> > |
| 31 |
> > :wq |
| 32 |
> |
| 33 |
> OK, I saw that comment but didn't grasp that it's the answer. Could be. |
| 34 |
> |
| 35 |
> Alternatively, in Michael's example earlier, I don't think the ldd |
| 36 |
> results for bash are changed (are they?) when ncurses is updated: |
| 37 |
> |
| 38 |
> [QUOTE] |
| 39 |
> $ ldd /bin/bash |
| 40 |
> linux-vdso.so.1 => (0x00007fffbafff000) |
| 41 |
> libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f0a4c278000) |
| 42 |
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f0a4c074000) |
| 43 |
> libc.so.6 => /lib64/libc.so.6 (0x00007f0a4bce4000) |
| 44 |
> /lib64/ld-linux-x86-64.so.2 (0x00007f0a4c4ce000) |
| 45 |
> [/QUOTE] |
| 46 |
|
| 47 |
They would change to |
| 48 |
|
| 49 |
$ ldd /bin/bash |
| 50 |
linux-vdso.so.1 => (0x00007fffbafff000) |
| 51 |
libncurses.so.5 => not found |
| 52 |
libdl.so.2 => /lib64/libdl.so.2 (0x00007f0a4c074000) |
| 53 |
libc.so.6 => /lib64/libc.so.6 (0x00007f0a4bce4000) |
| 54 |
/lib64/ld-linux-x86-64.so.2 (0x00007f0a4c4ce000) |
| 55 |
|
| 56 |
if the ebuild maintainer forgets to keep the *.so.5 version on the system in |
| 57 |
the *.so.6 update. That results in a broken bash. |
| 58 |
|
| 59 |
> It seems to me this is tending toward something similar to slots, |
| 60 |
> isn't it? If one package (bash) needs a specific version then can't we |
| 61 |
> find it using ldd (on every package on the system unfortunately) and |
| 62 |
> ensure that the needed .so files aren't removed? |
| 63 |
|
| 64 |
That's what ebuild maintainers do, afaik. |
| 65 |
|
| 66 |
~ $ equery b /usr/lib64/libpng14.so.14 |
| 67 |
* Searching for /usr/lib64/libpng14.so.14 ... |
| 68 |
media-libs/libpng-1.5.4 (/usr/lib64/libpng14.so.14) |
| 69 |
|
| 70 |
See? libpng14 is part of png-1.5.x package, so libpng14 is not removed, when |
| 71 |
you install the 1.5.x version. That keeps programs going. |
| 72 |
|
| 73 |
> /lib64/libncurses.so.5 & /lib64/libncurses.so.6 could both exist on |
| 74 |
> the system even if both version of the ncurses package don't. |
| 75 |
|
| 76 |
That's right. But keep in mind, that the old lib is outdated. Bugs remain |
| 77 |
bugs, nothing is fixed. Getting fixes, is why we update after all, isn't it? |
| 78 |
|
| 79 |
> I suspect this is mostly what revdep-rebuild is already doing, and I |
| 80 |
> also suspect my view of the problem is far too remedial... |
| 81 |
> |
| 82 |
> Thanks, |
| 83 |
> Mark |
| 84 |
|
| 85 |
Best, |
| 86 |
Michael |
Archives