<div dir="ltr"><div dir="ltr">Hi,</div><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On 2025年1月29日周三 19:32 Santiago Ruano Rincón <<a href="mailto:santiagorr@riseup.net" target="_blank">santiagorr@riseup.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Aron,<br>
<br>
Thanks a lot for your work on libxml2!<br>
<br>
El 21/08/24 a las 19:32, Aron Xu escribió:<br>
> On Mon, Aug 19, 2024 at 3:54 PM Emilio Pozuelo Monfort <<a href="mailto:pochu@debian.org" rel="noreferrer" target="_blank">pochu@debian.org</a>> wrote:<br>
> ><br>
> > On 17/08/2024 11:13, Paul Gevers wrote:<br>
> > > Hi,<br>
> > ><br>
> > > [Disclaimer: I'm not the most experienced person on transitions in the team, so<br>
> > > I'd like for Graham, Emilio and/or Sebastian to check if they agree with me.]<br>
> > ><br>
> > > Thanks for working on this.<br>
> > ><br>
> > > On 17-08-2024 05:58, Aron Xu wrote:<br>
> > >> After some research, I prefer making a t64-like transition for libxml2<br>
> > >> for the following reasons:<br>
> > ><br>
> > > I'm a bit curious in how far you think this looks like a t64-like transition as<br>
> > > apposed to a regular c-library transition. Is it because the libraries will not<br>
> > > be co-installable, you don't bump SONAME and just rename the binary package<br>
> > > name? Even with all the work that went into the t64 transition, we're starting<br>
> > > to see hidden bugs [0] (although I think this can happen with any transition).<br>
> > ><br>
> > >>   - Upstream is not prepared to bump the SONAME to something like<br>
> > >> libxml3. Given the long history of this function library, determining<br>
> > >> which APIs should be public and which should be private is<br>
> > >> challenging.<br>
> > ><br>
> > > That's why earlier I proposed a Debian specific SONAME, "in between" 2 and 3.<br>
> > > Upstream (I think) even suggested that [1].<br>
> > ><br>
> > >>   - The potential for breaking locally built software is minimal.<br>
> > >> Although abi-compliance-checker raises many issues, most of them are<br>
> > >> not used in the real world.<br>
> > ><br>
> > > Isn't the fact that we *caught* an issue in Debian the proof that it's not just<br>
> > > academic?<br>
> > ><br>
> > >>   - This approach is significantly easier and safer.<br>
> > ><br>
> > > I'm hesitant because we have well established procedures to handle ABI breakage<br>
> > > with SONAME bumps and how to handle them in Debian. Can you elaborate on the<br>
> > > easier and safer parts? Because I mostly see risks to deviate from established<br>
> > > paths as the corner cases on them are less known.<br>
> ><br>
> > I feel like the proposed change by Aron is the best course of action. The<br>
> > benefits are that we get everything rebuilt against the new package, effectively<br>
> > avoiding any issues with the ABI breaks inside Debian. And by maintaining the<br>
> > same SONAME as upstream, if a user installs a binary provided by a 3rd-party,<br>
> > then it will just work (assuming it was built for the newer releases or is not<br>
> > affected by the ABI breaks). The drawbacks are that the old and new packages<br>
> > won't be co-installable due to the file conflicts, and so the transition will<br>
> > have to happen in lockstep. It will also make it harder for apt to do the<br>
> > dist-upgrades from bookworm to trixie, which adds up to the t64 and possibly the<br>
> > usr-merge changes.<br>
> ><br>
> > Obviously there's an even better solution, which is for upstream to revert the<br>
> > ABI break (if possible) or bump the SOVERSION, but unfortunately that seems to<br>
> > be out of the picture.<br>
> ><br>
> <br>
> I've uploaded the debdiff to experimental, and the package should hit NEW soon.<br>
> <br>
> Thanks,<br>
> Aron<br>
<br>
May I ask you what are you plans for libxml2 > 2.9.x?<br>
<br>
The transition freeze is approaching (2025-03-15), and I would guess<br>
that packaging 2.13.x is too disruptive for trixie right now. Please,<br>
correct me if I am wrong! I would just like to document what are the<br>
expectations regarding the libxml2 version to be shipped with the new<br>
release.<br>
<br>
<br>
For a little bit of context, I am taking a look at the packages that<br>
have some CVEs open in unstable, and/or for which there is a new<br>
upstream version available, from an LTS perspective. This is with the<br>
idea of making it easier to provide security support for them thorough<br>
the full five years of the life cycle. If you want or need help, please<br>
don't hesitate to speak up. Someone from the LTS team may step up to<br>
help (CC'ing the LTS team).<br>
<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Thanks for taking care!</div><div><br></div><div>Aron</div></div></div></div>
</div>