Processed: Re: Bug#956510: spirv-tools: change to shared libraries breaks dpkg-shlibdeps during the build of reverse dependencies
Processing control commands: > forwarded -1 https://github.com/KhronosGroup/SPIRV-Tools/issues/3214 Bug #956510 [spirv-tools] spirv-tools: change to shared libraries breaks dpkg-shlibdeps during the build of reverse dependencies Set Bug forwarded-to-address to 'https://github.com/KhronosGroup/SPIRV-Tools/issues/3214'. -- 956510: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956510 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#956510: spirv-tools: change to shared libraries breaks dpkg-shlibdeps during the build of reverse dependencies
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
Bug#956510: spirv-tools: change to shared libraries breaks dpkg-shlibdeps during the build of reverse dependencies
Hi Simon On 2020-05-14 17:18:38 +0100, Simon McVittie wrote: > On Sun, 12 Apr 2020 at 11:04:38 +0200, Sebastian Ramacher wrote: > > libplacebo now manually links the libraries from spirv-tools > > (libSPIRV-Tools and libSPIRV-Tools-opt) to work-around #951988 and > > #955431. Since the switch to shared libraries, however, dpkg-shlibdeps > > is unable to produce the correct dependencies when linking those > > libraries. > > 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. From upstream's README: | The library contains all of the | implementation details, and is used in the standalone tools whilst also | enabling integration into other code bases directly. > If they're considered to be public libraries, then there are two options, > depending how stable they are: > > If their API/ABI are totally unmanaged, then they should probably be > provided as static-only, with libplacebo binNMU'd to pick up new versions. > > Or, if their API/ABI are managed, then they should have proper SONAMEs > (see upstream issues, as previously mentioned), and they should be > packaged like shared libraries, with a runtime library package per shared > library (or a single runtime library package if the upstream developer > guarantees that their SONAMEs all change in lockstep, like libglib2.0-0), > and one or more -dev packages. (See Policy §8 for details.) According to upstream's README, at least the API should be stable: | The interfaces have stabilized: We don't anticipate making a breaking | change for existing features. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#956510: spirv-tools: change to shared libraries breaks dpkg-shlibdeps during the build of reverse dependencies
On Sun, 12 Apr 2020 at 11:04:38 +0200, Sebastian Ramacher wrote: > libplacebo now manually links the libraries from spirv-tools > (libSPIRV-Tools and libSPIRV-Tools-opt) to work-around #951988 and > #955431. Since the switch to shared libraries, however, dpkg-shlibdeps > is unable to produce the correct dependencies when linking those > libraries. Are these libraries intended to be a public API, or are they intended to be a private implementation detail of the CLI tools? If they're a private implementation detail, then libplacebo shouldn't be linked to them, and they should either be statically linked into the various CLI tools, or installed to a private directory with a RUNPATH so that the CLI tools will find them (like the way /usr/bin/sudo links to the private library libsudo_util.so.0). If they're considered to be public libraries, then there are two options, depending how stable they are: If their API/ABI are totally unmanaged, then they should probably be provided as static-only, with libplacebo binNMU'd to pick up new versions. Or, if their API/ABI are managed, then they should have proper SONAMEs (see upstream issues, as previously mentioned), and they should be packaged like shared libraries, with a runtime library package per shared library (or a single runtime library package if the upstream developer guarantees that their SONAMEs all change in lockstep, like libglib2.0-0), and one or more -dev packages. (See Policy §8 for details.) smcv
Bug#956510: spirv-tools: change to shared libraries breaks dpkg-shlibdeps during the build of reverse dependencies
On 2020-04-12 11:04:38 +0200, Sebastian Ramacher wrote: > Package: spirv-tools > Version: 2020.2-1 > Severity: serious > > libplacebo now manually links the libraries from spirv-tools > (libSPIRV-Tools and libSPIRV-Tools-opt) to work-around #951988 and > #955431. Since the switch to shared libraries, however, dpkg-shlibdeps > is unable to produce the correct dependencies when linking those > libraries. During the build of libplacebo 1.29.1 it emits > > dpkg-shlibdeps: warning: can't extract name and version from library name > 'libSPIRV-Tools.so' > dpkg-shlibdeps: warning: can't extract name and version from library name > 'libSPIRV-Tools.so' > dpkg-shlibdeps: warning: can't extract name and version from library name > 'libSPIRV-Tools-opt.so' > dpkg-shlibdeps: warning: can't extract name and version from library name > 'libSPIRV-Tools-opt.so' > > and libplacebo29 is missing the dependencies for those libraries as a > consequence. And that's due to the libraries missing a SONAME. The corresponding upstream issues are https://github.com/KhronosGroup/SPIRV-Tools/issues/3046 and https://github.com/KhronosGroup/SPIRV-Tools/issues/3214 Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#956510: spirv-tools: change to shared libraries breaks dpkg-shlibdeps during the build of reverse dependencies
Package: spirv-tools Version: 2020.2-1 Severity: serious libplacebo now manually links the libraries from spirv-tools (libSPIRV-Tools and libSPIRV-Tools-opt) to work-around #951988 and #955431. Since the switch to shared libraries, however, dpkg-shlibdeps is unable to produce the correct dependencies when linking those libraries. During the build of libplacebo 1.29.1 it emits dpkg-shlibdeps: warning: can't extract name and version from library name 'libSPIRV-Tools.so' dpkg-shlibdeps: warning: can't extract name and version from library name 'libSPIRV-Tools.so' dpkg-shlibdeps: warning: can't extract name and version from library name 'libSPIRV-Tools-opt.so' dpkg-shlibdeps: warning: can't extract name and version from library name 'libSPIRV-Tools-opt.so' and libplacebo29 is missing the dependencies for those libraries as a consequence. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
