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

[Aron Xu]

On Sun, Aug 11, 2024 at 10:23 PM Aron Xu <aron at debian.org> wrote:
>
> Hi,
>
> On Sun, Aug 11, 2024 at 10:21 PM Paul Gevers <elbrus at debian.org> wrote:
> >
> > Hi Aron,
> >
> > On 14-07-2024 07:37, Paul Gevers wrote:
> > > On 28-06-2024 5:44 a.m., Aron Xu wrote:
> > >> Would like to know if such steps would help resolve the issue better:
> > >>   - revert to a previous version which does not have API/ABI breakage
> > >>   - apply/port security patches on a best effort basis
> > >>   - help upstream to check and fix API/ABI changes
> > >
> > > I think all three would help, where the first one is the quickest one to
> > > get things moving again. Given the severity of the security issue
> > > mentioned in the changelog I think you could even consider ignoring item
> > > number two for now, but maybe you mean going forward.
> > >
> > >> Or do you have any recommendations?
> > >
> > > There is the option to do a Debian specific SONAME bump, but if the
> > > break was not intended and might get reverted that's probably a bad
> > > idea. And if the changes are here to stay, upstream should bump SONAME
> > > themselves.
> >
> > While the upstream bug about the soname breakage seems to have halted,
> > can we please get some resolution in Debian please? The fact that
> > libxml2 can't migrate as-is is hurting more and more (particularly the
> > creation of a useful testing for riscv64).
> >
> > If upstream is really reluctant to bump SONAME when they should, maybe
> > you should prepare for a maintenance scheme to do that in Debian when
> > needed. Ideally the scheme should be designed such that when upstream
> > bumps SONAME, you can follow them again.
> >
>
> Thanks for pinging again!
>

After some research, I prefer making a t64-like transition for libxml2
for the following reasons:
 - 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.
 - 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.
 - This approach is significantly easier and safer.

I've prepared a preliminary debdiff and tested locally. What do you think?

Thanks,
Aron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libxml2_2.13.3+dfsg-0exp1.debdiff
Type: application/octet-stream
Size: 15669 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debian-xml-sgml-pkgs/attachments/20240817/9e98d905/attachment-0003.obj>