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
