Package: spirv-tools
Version: 2020.6-1
Severity: important
If a package is linked to the libSPIRV-Tools-shared.so shared library,
then it will get a runtime dependency on libSPIRV-Tools-shared.so.
However, libSPIRV-Tools-shared.so is currently bundled into the
spirv-tools binary package rather than being packaged in accordance with
Policy §8.
libSPIRV-Tools-shared.so should be in a package named
libspirv-tools-shared. There should probably also be a libspirv-tools-dev
package containing the static libraries and pkg-config metadata. Ideally
both of those packages would be Multi-Arch: same.
Unfortunately, this will require a trip through the NEW queue.
libspirv-tools-shared needs to provide either a shlibs or symbols file,
as per Policy §8.6, so that ${shlibs:Depends} works correctly.
Unfortunately the form of the SONAME used by upstream (with no version
number) doesn't seem to be compatible with shlibs files, so I think there
is no choice but to use a symbols file. This is going to be annoying
because symbols files for C++ ABIs are not easy, but you could consider
having a libspirv-tools-shared.symbols.in file like this:
libSPIRV-Tools-shared.so libspirv-tools-shared #MINVER#
* Build-Depends-Package: libspirv-tools-dev
(regex)".*" @DEB_VERSION_UPSTREAM@
and generating libspirv-tools-shared.symbols by substituting
@DEB_VERSION_UPSTREAM@, to get the equivalent of a legacy shlibs file?
If it cannot be packaged as a correct shared library for technical reasons
then I would recommend going back to it being static-only, which seems like
a lesser evil than having a non-Policy-compliant shared library.
smcv