On 17/08/2024 11:13, Paul Gevers wrote:
Hi,
[Disclaimer: I'm not the most experienced person on transitions in the team, so
I'd like for Graham, Emilio and/or Sebastian to check if they agree with me.]
Thanks for working on this.
On 17-08-2024 05:58, Aron Xu wrote:
After some research, I prefer making a t64-like transition for libxml2
for the following reasons:
I'm a bit curious in how far you think this looks like a t64-like transition as
apposed to a regular c-library transition. Is it because the libraries will not
be co-installable, you don't bump SONAME and just rename the binary package
name? Even with all the work that went into the t64 transition, we're starting
to see hidden bugs [0] (although I think this can happen with any transition).
- Upstream is not prepared to bump the SONAME to something like
libxml3. Given the long history of this function library, determining
which APIs should be public and which should be private is
challenging.
That's why earlier I proposed a Debian specific SONAME, "in between" 2 and 3.
Upstream (I think) even suggested that [1].
- The potential for breaking locally built software is minimal.
Although abi-compliance-checker raises many issues, most of them are
not used in the real world.
Isn't the fact that we *caught* an issue in Debian the proof that it's not just
academic?
- This approach is significantly easier and safer.
I'm hesitant because we have well established procedures to handle ABI breakage
with SONAME bumps and how to handle them in Debian. Can you elaborate on the
easier and safer parts? Because I mostly see risks to deviate from established
paths as the corner cases on them are less known.
I feel like the proposed change by Aron is the best course of action. The
benefits are that we get everything rebuilt against the new package, effectively
avoiding any issues with the ABI breaks inside Debian. And by maintaining the
same SONAME as upstream, if a user installs a binary provided by a 3rd-party,
then it will just work (assuming it was built for the newer releases or is not
affected by the ABI breaks). The drawbacks are that the old and new packages
won't be co-installable due to the file conflicts, and so the transition will
have to happen in lockstep. It will also make it harder for apt to do the
dist-upgrades from bookworm to trixie, which adds up to the t64 and possibly the
usr-merge changes.
Obviously there's an even better solution, which is for upstream to revert the
ABI break (if possible) or bump the SOVERSION, but unfortunately that seems to
be out of the picture.
Cheers,
Emilio
