On Sat, 22 Jan 2022 at 08:58:37 +0800, Paul Wise wrote: > On Fri, 2022-01-21 at 13:55 -0500, Theodore Ts'o 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 don't think characterizing that as irresponsible is entirely fair, and it risks setting up incentives that harm us: if the upstream for a package I maintain is breaking backwards-compat, I'd prefer them to acknowledge it and bump the SONAME, rather than saying "well, it isn't *that* big a break" and ignoring it. > 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. I used that method for early GTK 4 prereleases in experimental, when upstream were breaking ABI in each 3.9x prerelease. They specifically weren't guaranteeing API or ABI stability yet at that stage in development, but I wanted to start packaging early, before it was too late to incorporate feedback that could result in further incompatible changes. (At the time the source package was called src:gtk+4.0, but it's in the git history of src:gtk4 now.) I think this is fine for prereleases and experimental, but for packages with more than a trivial number of reverse-dependencies it is likely to cause issues for testing/unstable transitions, because it defeats the release team's "smooth upgrades" mechanism (in which they keep the old libfoo1 binaries and the old src:foo in testing until there are no more rdeps, even after they have been superseded by a new src:foo with libfoo2, so that migration doesn't have to all happen in one go). I would say that maintainers who are considering doing this in unstable should talk to the release team first. smcv