On Thu, 11 Feb 2021 at 14:33:37 +0200, Timo Aaltonen wrote: > Uh, the shared lib was supposed to be disabled in 2020.3-1, but looks like > the build option broke since. But 2020.6 now has this merged: > > https://github.com/KhronosGroup/SPIRV-Tools/pull/3910 > > which should allow building a proper shared lib, but still without > versioning. I wonder what to do for bullseye, maybe force static like it's > supposed to be and be happy for now?
I think the first thing to do is to disable (or just not install!) the shared library. That doesn't need a trip through NEW and should be straightforward; it would be good if that change can be included in bullseye. https://codesearch.debian.net/search?q=SPIRV-Tools-shared&literal=1 seems to indicate that nothing depends on SPIRV-Tools-shared yet. All the search hits are in packages that bundle a copy of SPIRV-Tools, except for vkd3d which only links to the shared library if you enable an option that Debian apparently doesn't, and mojoshader, which is more complicated. mojoshader doesn't *seem* to have a runtime dependency on libSPIRV-Tools-shared, but it checks for the -shared pkg-config data, so it might accidentally FTBFS after disabling the shared library - but it has a popcon score of 3 and nothing depends on it, so I don't think you should necessarily feel guilty about breaking it? The long-term solution is to teach upstream how SONAMEs work (I already tried on <https://github.com/KhronosGroup/SPIRV-Tools/issues/3214>, but it seems to be a slow process); and then when that has happened, package the library according to Policy (libspirv-tools-dev and libspirv-tools0, or similar) and go through NEW. smcv
