Bug#1072012: libxml-libxml-perl: new upstream release 2.0210, addressing test failures with libxml2 >= 2.11

[Aron Xu]

Hi,

On Thu, May 30, 2024 at 4:15 AM Niko Tyni <ntyni at debian.org> wrote:
>
> On Wed, May 29, 2024 at 02:16:47PM +0800, Aron Xu wrote:
> > On Wed, May 29, 2024 at 12:16 AM gregor herrmann <gregoa at debian.org> wrote:
>
> > > Warning: program compiled against libxml 212 using older 209
> > >
> > > and this comes from libxml:
> > >
> > > https://sources.debian.org/src/libxml2/2.12.7+dfsg-2/parserInternals.c/?hl=79#L79
> > >
> > >     if ((myversion / 100) < (version / 100)) {
> > >         xmlGenericError(xmlGenericErrorContext,
> > >                 "Warning: program compiled against libxml %d using older %d\n",
> > >                 (version / 100), (myversion / 100));
> > >     }
> > >
> > >
> > > Not sure if this is should be fixed in libxml2 or if we should add an
> > > artifical dependency on a newer libxml2 (to avoid testing against the
> > > version in testing). The former sounds more logic to me.
> > >
> >
> > Although it looks trivial to remove the warning from libxml2, I'm
> > reluctant since this piece of code existed for a very long time, a
> > random check shows that version 2.2.3 (in 2000) has the logic:
> > https://gitlab.gnome.org/GNOME/libxml2/-/blob/04698d9e1c56467007fcbb9472e5db67cf5938f5/parserInternals.c#L66
>
> I'm a bit surprised that we haven't suffered from this before.  We've been
> patching away similar things on the libxml-libxml-perl side.
>
> But I see it only triggers with libxml2 "middle version" changes (2.x -> 2.y), and
> the last time that happened in Debian was in 2013. The autopkgtest checks were
> not a thing back then, and I guess we've just tolerated the stderr warnings
> or requested a rebuild of libxml-libxml-perl.
>
> I suppose rebuilding on these "middle version" libxml2 changes is okay if
> you want to keep the warning, even if the rebuild is strictly speaking
> unnecessary. It's even conceivable that XML::LibXML might pick up new
> features with the rebuild (for better or worse.)
>
> But I think we should add dependency metadata so that the release team,
> britney, debci etc. can see the need for a rebuild when we have a
> "broken" combination, and then hint the "correct" versions for testing
> migration together.  Updating libxml2 "middle version" would then mean
> a mini-transition.
>
> At the moment that would mean having libxml-libxml-perl
>   Depends: libxml2 (>> 2.12), libxml2 (<< 2.13~)
> or something like that, with the numbers automatically generated during
> the build of course.
>
> And libxml2 would need a one-time
>   Breaks: libxml-libxml-perl (<<  2.0207+dfsg+really+2.0134-3)
> or whichever version introduces the above dependencies.
>

I'm fine with the resolution and I have committed a similar thing to
libxml2 following gregoa's advice:
https://salsa.debian.org/xml-sgml-team/libxml2/-/commit/f0f2fc3a207aed66e651b0d75ecea2d9b2028c8c

I plan to upload soon after doing some further research about #1072017
in src:ruby-libxml.

Thanks,
Aron