On 2013-06-30 22:46, Dave Steele wrote: > On Sun, Jun 30, 2013 at 1:08 PM, Julien Cristau <jcris...@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). Andreas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51d140a6.80...@debian.org
