Re: Help needed with a dh_shlibs failure on non amd64 platforms
On Mon, 04 Jul 2022 at 09:29:54 +0200, Martin Quinson wrote:
> All libraries (eg libns3-bridge.so.36.1) that it cannot find are part of the
> package. They are added to the debian/libns3.36/DEBIAN/shlibs
Independent of the dh_shlibdeps failure that was already diagnosed, if
these libraries are public (i.e. other packages in Debian are allowed to
link against them) and the SONAMEs of the libraries are of the form
libns3-*.so.36.1, then the binary package that contains them should
probably be called something like libns3-36.1, rather than libns3.36.
(Either that, or they should be split up into one binary package per
library, named like libns3-bridge36.1 and so on, by mechanically
transforming their SONAMEs according to the convention documented
in Policy - but I can understand why you would prefer not to do that when
there are a large number of libraries with matching versioning.)
Otherwise, when the SONAMEs jump from libns3-*.so.36.1 to libns3-*.so.36.2
in a future version, any dependent packages that require libns3-*.so.36.1
would be broken by upgrading libns3.36 to a version that no longer contains
libns3-*.so.36.1.
> If you wonder, the cmake macro to define and build a library is in
> ns-3.36.1/build-support/custom-modules/ns3-module-macros.cmake
> I already had to patch it to support Debian:
> https://salsa.debian.org/debian/ns3/-/blob/master/debian/patches/library-soversion.diff
> This patch is ugly for now, but I'm already discussing with upstream so that
> they integrate the spirit of this patch to their code. They are receptive.
If you're giving advice to upstream, it's important to be aware of
whether the libraries are private (only to be used by other binary
packages within the same source package, like samba-libs or
libsystemd-shared) or public (with a -dev package that can validly be
used by other source packages, like libsmbclient or libsystemd0 or any
typical shared library like GTK or Qt). The correct advice to give to an
upstream for private shared libraries is not the same as the correct
advice for public shared libraries.
smcv
Reply to: