Bug#1115395: dpkg-shlibdeps fails to find libraries if /lib is removed from ld.so.conf search path

[Guillem Jover]

On Wed, 2025-09-17 at 23:10:55 +0200, Michael Biebl wrote:
> Am 17.09.25 um 23:04 schrieb Guillem Jover:
> > On Wed, 2025-09-17 at 22:09:34 +0200, Michael Biebl wrote:
> > > Control: severity -1 serious
> > 
> > > As this resulted in broken shlibs dependencies, I'm bumping the
> > > severity to RC. This might even be something you might want to fix
> > > via a stable upload as the packages depending on libgctp are
> > > currently broken in stable.
> > 
> > Just for clarification just in case (given that the wording seems
> > to imply something else), the packages are breaking dpkg-shlibdeps
> > assumptions in how they are shipping the shared library and its
> > symlinks, the shlibs file it provides should be fine by itself (and
> > the patch should not be changing its contents).
> > 
> > For stable I'd assume that given a default Debian system with
> > merged-/usr via directory aliasing and with /lib in ld.so.conf,
> > there should be no breakage, even though the package is still
> > broken (but should in theory not trigger breakage in dpkg-shlibdeps
> > there). So while I think fixing it there would make sense to me,
> > it should not be needed to solve any FTBFS.
> 
> The point is, packages in stable have a dependency on libgctp-2.0.0
> while libgctp-2.0.0.so is actually provided by libgctp-dev.
> 
> So installing rdeps of libgctp-2.0.0 results in a broken setup.

Ah, I see what you mean. Although that should also be shadowed by
ldconfig generating the missing SONAME symlinked to to real library
filename when installing libgctp-2.0.0. So the SONAME symlink will
be unowned (in dpkg terms), but dpkg will overwrite it when installing
libgctp-dev. So while this is also broken, it should not cause
visible breakage either (I think).

Thanks,
Guillem