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

[Niko Tyni]

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.

Does that make sense or sound overkill?
-- 
Niko