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
