Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.rc > #370274

Bug#1073508: Bug#1074338: Bug#1073508: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue

Show all headers | View raw

On Mon, Aug 19, 2024 at 3:54 PM Emilio Pozuelo Monfort <pochu@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

Back to linux.debian.bugs.rc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Bug#1073313: gnustep-base: FTBFS: GSXML.m:2674:22: error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’ Lucas Nussbaum <lucas@debian.org> - 2024-06-16 15:00 +0200
  Processed: Re: Bug#1073313: gnustep-base: FTBFS: GSXML.m:2674:22:  error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’ "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-06-16 18:50 +0200
  Bug#1073313: gnustep-base: FTBFS: GSXML.m:2674:22: error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’ Thorsten Glaser <t.glaser@qvest-digital.com> - 2024-06-16 19:10 +0200
  Bug#1073313: another libxml2 ABI break, might need RM attention (Re: Bug#1073313: gnustep-base: FTBFS: GSXML.m:2674:22: error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’) Thorsten Glaser <t.glaser@qvest-digital.com> - 2024-06-16 19:20 +0200
  Bug#1073508: libxml2: just another API+ABI break; please bump soname Aron Xu <aron@debian.org> - 2024-06-17 09:50 +0200
    Bug#1073508: libxml2: just another API+ABI break; please bump soname Thorsten Glaser <t.glaser@qvest-digital.com> - 2024-06-17 16:50 +0200
  Processed: Re: libxml2: just another API+ABI break; please bump  soname "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-06-17 09:50 +0200
  Bug#1073313: marked as done (gnustep-base: FTBFS: GSXML.m:2674:22:  error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-06-19 11:30 +0200
  Bug#1073508: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue Aron Xu <aron@debian.org> - 2024-08-11 16:30 +0200
    Bug#1073508: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue Bo YU <tsu.yubo@gmail.com> - 2024-08-16 09:50 +0200
  Bug#1073508: Bug#1074338: Bug#1073508: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue Aron Xu <aron@debian.org> - 2024-08-17 08:30 +0200
  Bug#1073508: Bug#1074338: Bug#1073508: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue Aron Xu <aron@debian.org> - 2024-08-17 14:10 +0200
  Bug#1073508: Bug#1074338: Bug#1073508: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue Aron Xu <aron@debian.org> - 2024-08-21 13:40 +0200
  Bug#1073508: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue Aurelien Jarno <aurel32@debian.org> - 2024-08-21 19:50 +0200
  Bug#1073508: marked as done (libxml2: just another API+ABI break;  please bump soname) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-09-26 18:00 +0200
  Bug#1073508: is this really fixed? looks like not yet Francesco Potortì <Potorti@isti.cnr.it> - 2024-12-17 14:40 +0100

csiph-web