On Mon, Jul 01, 2013 at 10:41:10AM +0200, Andreas Beckmann wrote: > On 2013-06-30 22:46, Dave Steele wrote: > > On Sun, Jun 30, 2013 at 1:08 PM, Julien Cristau <jcristau@debian.org> wrote: > >> AFAIK most of these get fixed up by ldconfig, which means they're not a > >> problem in practice. > > > > It wasn't clear to me how this would be the case, so I reran the logs > > with a piuparts mod making an ldconfig call before the symlink test. > > It did not affect the results. > > Proper package installation would include a ldconfig call that should > have fixed the broken link *before* piuparts checks for dangling links. > (IIRC there is currently only one package "needing" this ldconfig call > to actually create a link: libjson0/libjson-c2, #710676). So either a > call to ldconfig is missing (bug!) or it's not ldconfig's job to fix up > a dangling e.g. > libfoo.so -> libfoo.so.2 > symlink (because it's a missing dependency). > > On 2013-07-01 03:29, Chow Loong Jin wrote: > > I believe that he's referring to ld.so.cache containing a mapping of > $SONAME -> > > $lib_realpath, so the broken symlink might not actually result in an > > unresolvable library. > > But most of these broken links don't look like broken SONAME links (as > they would have been fixed up by ldconfig). Oh cool, I didn't realize ldconfig corrected the symlinks. -- Kind regards, Loong Jin
Attachment:
signature.asc
Description: Digital signature