Hi! El 02/02/25 a las 22:29, Aron Xu escribió: > On 2025年1月29日周三 19:32 Santiago Ruano Rincón <santiag...@riseup.net> wrote: > > > On Mon, Aug 19, 2024 at 3:54 PM Emilio Pozuelo Monfort <po...@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
signature.asc
Description: PGP signature
