On Sat, Jan 22, 2022 at 08:58:37AM +0800, Paul Wise wrote: > > The other thing that's perhaps considering here is that unfortunately, > > there are some upstreams that are extremely irresponsible with library > > ABI backwards compatibility, where they bump the SONAME essentially at > > every release. I recall one extreme case a few years ago where there > > were over ten(!) SONAME bumps for a particular library over 12 months. > > You could avoid NEW for these SONAME bumps by using a single binary > package and ensuring that the symbols/shlibs depend on the right > version ranges. Or add Provides libfoo-abi-N or libfoo-abi (= N) > and have the symbols and or shlibs generate dependencies on that.
That only works if there are no other packages depending on those shared libraries which are coming from other source packages. After all, if the only consumers of those shared libraries is source package for those libraries, there's a much simpler solution --- just compiling the d*mned package using static linking, and just moving on. But if there are other packages which are using those shared libraries, then the official party line is that just shipping static libraries in libshaky-dev is bad, Bad, BAD, since it means that when there are security bugs fixed in the sources for libshaky, they aren't automatically fixed for all of the users of libshaky until they relink. But my claim is that if the upstream can't manage to maintain a stable ABI, then maybe we shouldn't be trying to ship shared libraries. But officially, that's not allowed, since it's considered bad. Unfortunately, that's effectively punishing maintainers who are supporting sources which support shared library. For those languages like Rust, etc., which don't support shared libraries, life is *much* simpler. > In the past I've suggested a solution to static linking and binary > packages containing source could be to have a service scanning every > binary package for static/source files (.a, Rust, Golang etc), noting > the relevant package/version tuples and then searching the buildinfo > files for binary packages that built with those packages installed and > automatically rebuilding affected packages, or having a service that > would let you manually rebuild packages affected by security issues. > > https://wiki.debian.org/StaticLinking If we have that solution for Rust and Golang, the maybe it can also make life easier for upstreams that can't maintain an ABI. (And yes, I don't have much patience with those folks given that e2fsprogs has had a stable library since 1997, which is the last time I've had to bump an SONAME for libext2fs. But that's because I'm careful, where as some other developers like for f2fs-tools, bump their SONAME every !@#@?! release. Sigh...) - Ted