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

[Rene Engelhard]

Hi,

Am 17.08.24 um 05:58 schrieb Aron Xu:
> 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.
> [...]
> I've prepared a preliminary debdiff and tested locally. What do you think?
-       dh_makeshlibs -plibxml2 -V 'libxml2 (>= 2.9.11)' -- -c4
+       dh_makeshlibs -plibxml2n -V 'libxml2 (>= 2.9.11)' -- -c4

Look wrong to me, should be libxml2 in the version, too.


--- libxml2-2.13.3+dfsg/debian/libxml2n.symbols 1970-01-01 08:00:00.000000000 +0800
+++ libxml2-2.13.3+dfsg/debian/libxml2n.symbols 2024-08-16 22:13:37.000000000 +0800
@@ -0,0 +1,146 @@
+libxml2.so.2 libxml2 #MINVER#
[...]

here, too.


Otherwise stuff built against the NEW ABI still gets dependencies fullfillable by old ones.


For the same reason

+Provides: libxml2 (= ${binary:Version})

is bad, that is the other way round and stuff using the old ABI will happily install with libxml2n.

(That Provides: was there in t64 where the ABI didn't change, aka all 64bit + i386)


And I *think* you need Breaks/Conflicts in addition to Replaces at the new libxml2n.


Regards,


Rene