Re: Bug#994758: libsgutils2-2: how to prevent the share lib from changing version to impact the package?
On Mon, 20 Sep 2021 at 17:25:32 +0200, Chris Hofstaedtler wrote:
> * Hsieh-Tseng Shen <woodrow.shen@gmail.com> [210920 16:54]:
> > The ledmon package was reported by
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994521 to cause ledmon
> > service was unable to run due to the broken dependency of libsgutils2-2.
> >
> > It seems like the softlink will keep changing since 1.45:
>
> Upstream change:
> https://github.com/hreinecke/sg3_utils/commit/b0042ccf801d0008c0f9f090ea93b3871e8a542e
> ("add ${PACKAGE_VERSION} to '.so' name")
>
> *Maybe* libsgutils2-2 should now also carry the version in its
> package *name* :-(
This looks to me like one of three things:
- A mistake
- If it's this, please talk to upstream about fixing it
- A library whose upstream intends it to be available to third parties
but does not intend to keep the ABI stable between releases
- If it's this, then one option is for our binary package to be named
something like libgsutils2-1.46-2 and go through NEW for every new
upstream release, with every new upstream release being a transition;
another option is to make it a static-only library with only a .a in
the -dev package, like libdpkg-dev and glslang-dev, with binNMUs
of dependent packages when it gets updated. Either way the release
team would need to be involved in updates.
- A library whose upstream intends it to be unstable and private to the
source package, with no third-party uses
- If it's this, then one option is for sg3-utils to link it statically
or put it in a private directory and stop providing a
libsgutils2-dev package, in which case ledmon, libgpod and
tableau-parm would need to vendor a copy under their control and
take responsibility for security updates; another option is (again)
to make it a static-only library with only a .a in the -dev package,
like binutils-dev, libdpkg-dev and glslang-dev
Whichever one it is, here are some recommendations for maintainers of any
shared library:
- Talk to upstream about how they intend this library to work, whenever
it's unclear - diverging from upstream on matters of ABI rarely ends well
- Pay attention when Lintian emits package-name-doesnt-match-sonames, it's
there to help you
- Be careful with wildcards in shared libraries' .install files: they make
it easy to not notice a SONAME bump
- When you update the .symbols file, don't just mechanically update it to
whatever makes the new package compile: think about whether the change
is an incompatible one that will break existing programs (this is part
of the purpose of a .symbols file)
I hope this helps,
smcv
Reply to: