[xml/sgml-pkgs] Bug#1074338: Bug#1073508: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue

[Aron Xu]

On Mon, Aug 19, 2024 at 3:54 PM Emilio Pozuelo Monfort <pochu at debian.org> wrote:
>
> 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.
>

I've uploaded the debdiff to experimental, and the package should hit NEW soon.

Thanks,
Aron