Bug#980370: spirv-tools: shared library should be packaged like a shared library
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
Reply to: