Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not
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
Reply to: