On Mon, 20 Sep 2021 at 17:25:32 +0200, Chris Hofstaedtler wrote: > * Hsieh-Tseng Shen <woodrow.s...@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