Bug#956510: spirv-tools: change to shared libraries breaks dpkg-shlibdeps during the build of reverse dependencies

[Simon McVittie <smcv@collabora.com>]

Control: forwarded -1 https://github.com/KhronosGroup/SPIRV-Tools/issues/3214

On Fri, 15 May 2020 at 10:16:33 +0200, Sebastian Ramacher wrote:
> On 2020-05-14 17:18:38 +0100, Simon McVittie wrote:
> > Are these libraries intended to be a public API, or are they intended to be
> > a private implementation detail of the CLI tools?
> 
> They are intended to be public.

In that case I think the necessary steps are:

- wait for upstream to set an official SONAME
  - someone from Collabora can propose a PR if upstream say it would be
    helpful, or if that seems to be necessary to unblock the upstream issue

- change the Debian package to be built like a Policy §8 shared library:
  - libspirv-tools-dev
  - libspirv-tools0
  - possibly also libspirv-tools-link0, etc., depending whether upstream
    say the SONAMEs are meant to go up in lockstep or separately
    (the safe/conservative option is one binary package per shared library)
  - again, someone from Collabora can propose patches for this if necessary
  - the upstream action needs to happen first, to avoid Debian producing an
    ABI that is incompatible with upstream

- NEW queue processing

Thanks,
    smcv