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

[Santiago Ruano Rincón]

Hi!

El 02/02/25 a las 22:29, Aron Xu escribió:
> On 2025年1月29日周三 19:32 Santiago Ruano Rincón <santiagorr at riseup.net> wrote:
> > > 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
> >
> > May I ask you what are you plans for libxml2 > 2.9.x?
> >
> > The transition freeze is approaching (2025-03-15), and I would guess
> > that packaging 2.13.x is too disruptive for trixie right now. Please,
> > correct me if I am wrong! I would just like to document what are the
> > expectations regarding the libxml2 version to be shipped with the new
> > release.
> >
> >
> > For a little bit of context, I am taking a look at the packages that
> > have some CVEs open in unstable, and/or for which there is a new
> > upstream version available, from an LTS perspective. This is with the
> > idea of making it easier to provide security support for them thorough
> > the full five years of the life cycle. If you want or need help, please
> > don't hesitate to speak up. Someone from the LTS team may step up to
> > help (CC'ing the LTS team).
> >
> >
> Upstream promised to release 2.14 (with SONAME bumped) soon, and he just
> replied to your comment on GNOME gitlab that his latest plan is February.
> Let's hold breath for that and try to coordinate a transition if that
> happens... or if that fails (not release in time or too hard to transition)
> let's start maintain our branch of 2.9.x to include as many as fixes
> possible.

Yeah, let's see. I guess it also a question of balance (as always),
between having tested library and a bleeding-edge available in trixie.

In any case, when it gets released, please don't hesitate to ask if you
would like some help to test how reverse build depends gets built.

> Thanks for taking care!

Thanks for your work!

 -- S
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debian-xml-sgml-pkgs/attachments/20250203/4c42f560/attachment.sig>