Bug#956510: spirv-tools: change to shared libraries breaks dpkg-shlibdeps during the build of reverse dependencies
On Sun, 12 Apr 2020 at 11:04:38 +0200, Sebastian Ramacher wrote:
> libplacebo now manually links the libraries from spirv-tools
> (libSPIRV-Tools and libSPIRV-Tools-opt) to work-around #951988 and
> #955431. Since the switch to shared libraries, however, dpkg-shlibdeps
> is unable to produce the correct dependencies when linking those
> libraries.
Are these libraries intended to be a public API, or are they intended to be
a private implementation detail of the CLI tools?
If they're a private implementation detail, then libplacebo shouldn't be
linked to them, and they should either be statically linked into the
various CLI tools, or installed to a private directory with a RUNPATH
so that the CLI tools will find them (like the way /usr/bin/sudo links
to the private library libsudo_util.so.0).
If they're considered to be public libraries, then there are two options,
depending how stable they are:
If their API/ABI are totally unmanaged, then they should probably be
provided as static-only, with libplacebo binNMU'd to pick up new versions.
Or, if their API/ABI are managed, then they should have proper SONAMEs
(see upstream issues, as previously mentioned), and they should be
packaged like shared libraries, with a runtime library package per shared
library (or a single runtime library package if the upstream developer
guarantees that their SONAMEs all change in lockstep, like libglib2.0-0),
and one or more -dev packages. (See Policy §8 for details.)
smcv
Reply to: