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