[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 Sat, Aug 17, 2024 at 5:15 PM Paul Gevers <elbrus at debian.org> 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).
>

Doing this through a t64-like transition would:
1. Make package build with new libxml2 depends on new package
2. Still potentially break user built binaries using older versions

The most undetectable bugs are lying in binaries using data types that
have changed, which is not tracked by upstream.

> >   - 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].
>

I'm not sure whether upstream really means everyone should really make
their own SONAME, I think it's more like a disclaimer that it's not
his opinion to bump SONAME but feel free if there are people who
insist on doing so.


> >   - 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?
>

And it is a case of accessing changed data type, which is the case not
tracked by upstream.

> >   - 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.
>

Well I would like to know if it's really desirable to divert from
upstream, to bump to something like libxml2.1?

> > I've prepared a preliminary debdiff and tested locally. What do you think?
>
> Also just curious, why the letter n?

This is just picked randomly.

>
> Paul
>
> [0] https://lists.debian.org/msgid-search/Zr57AYhXiL3oi8_d@per
> [1] https://gitlab.gnome.org/GNOME/libxml2/-/issues/751#note_2157870
> (second to last paragraph)