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

[Aurelien Jarno]

Hi,

Sorry to be late to the party.

On 2024-08-19 09:51, Emilio Pozuelo Monfort 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

It also means that at least gettext will need to get reboostrapped on
all architectures. Indeed the new libxml2-dev won't be co-installable with 
debhelper, which is a build-dependency of gettext:
- libxml2-dev will depend on libxml2n 
- debhelper will still depend (through debhelper) on libxml2

What are the plans with regard to that? Note that I haven't check
further in the (build)-dependency tree.

Cheers
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien at aurel32.net                     http://aurel32.net