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
