[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not



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


Reply to: