Rafael
* Rene Engelhard <r...@debian.org> [2023-12-25 23:48]:
Hi,
Am 25.12.23 um 22:57 schrieb Rene Engelhard:
I didn't file it for the plain build issue. Nevertheless, if it
broke so many projects you probably should do a full-fledged rebuild
and send
Well, mitigated by 2.12.3, but still.
But again, this is completely off-topic to what I filed in this bug
which is the ABI break.
Which *maybe* could be ignored. Maybe one can do Breaks: after a
rebuild (then you might get a problem inbetween only when in this case
libreoffice is to be rebuilt. But here libreoffice fails its tests
even).
But not until one knows what is affected.
*You* need to do a test as the library maintainer/the one who wants to
update it, not me.
The current issue has the potential of introducing a *huge* breakage in
the distribution, due to the chain of (build-)dependencies. For instance,
I tried to rebuild the plplot package in my up-to-date experimental
chroot, in order to make it comply with the upcoming gnat-12 ⇒ gnat-13
transition. I ran into this, when trying to install the
build-dependencies for plplot :
$ pdebuild
[…]
Setting up octave (8.4.0-1+b1) ...
/usr/bin/octave-cli: symbol lookup error: /lib/libGraphicsMagick-Q16.so.3:
undefined symbol: xmlNanoFTPInit, version LIBXML2_2.4.30
dpkg: error processing package octave (--configure):
[…]
Errors were encountered while processing:
octave
E: Sub-process /usr/bin/dpkg returned an error code (1)
If a new version of graphicsmagick were uploaded to experimental, then
the problem would go away. Indeed, when the graphicsmagick package is
rebuilt in experimental, the configure script does detect the absence of
the xmlNanoFTPNewCtxt function in the libxml2 library (version
2.12.3+dfsg-0exp1) and disables the call to the xmlNanoFTP* functions.
However, this rebuilt will not be automatically triggered without a bump
in the SONAME version of libxml2.
In summary, the introduction of version 2.12 of libxml2 in unstable will
need a proper and coordinated transition.
Best,
Rafael Laboissière
