Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue

[Aron Xu]

Hi,

Source: libxml2
Version: 2.9.14+dfsg-1.3
Severity: serious
Control: close -1 2.12.7+dfsg-3
Tags: sid trixie
Usertags: out-of-sync
Control: block -1 by 1073508
Dear maintainer(s),
The Release Team considers packages that are out-of-sync between testing
and unstable for more than 30 days as having a Release Critical bug in
testing [1]. Your package src:libxml2 has been trying to migrate for 32
days [2]. Hence, I am filing this bug. The version in unstable broke ABI
without a SONAME bump as reported in bug 1073508.

I would like to seek for your advice on how to handle this issue, the
stuff looks a bit complicated:
- upstream is responsive and helpful, but the current handling of
API/ABI could be problematic
- there is no plan to bump SONAME at this moment
- need time to do in-depth check of API/ABI breakages

Would like to know if such steps would help resolve the issue better:
- revert to a previous version which does not have API/ABI breakage
- apply/port security patches on a best effort basis
- help upstream to check and fix API/ABI changes

Or do you have any recommendations?

Thanks,
Aron

[Paul Gevers]

Hi Aron,

Post by Aron Xu
- revert to a previous version which does not have API/ABI breakage
- apply/port security patches on a best effort basis
- help upstream to check and fix API/ABI changes

I think all three would help, where the first one is the quickest one to
get things moving again. Given the severity of the security issue
mentioned in the changelog I think you could even consider ignoring item
number two for now, but maybe you mean going forward.

Post by Aron Xu
Or do you have any recommendations?

There is the option to do a Debian specific SONAME bump, but if the
break was not intended and might get reverted that's probably a bad
idea. And if the changes are here to stay, upstream should bump SONAME
themselves.

Paul

[Paul Gevers]

Hi Aron,

Post by Paul Gevers

  - revert to a previous version which does not have API/ABI breakage
  - apply/port security patches on a best effort basis
  - help upstream to check and fix API/ABI changes

I think all three would help, where the first one is the quickest one to
get things moving again. Given the severity of the security issue
mentioned in the changelog I think you could even consider ignoring item
number two for now, but maybe you mean going forward.

Or do you have any recommendations?

There is the option to do a Debian specific SONAME bump, but if the
break was not intended and might get reverted that's probably a bad
idea. And if the changes are here to stay, upstream should bump SONAME
themselves.

While the upstream bug about the soname breakage seems to have halted,
can we please get some resolution in Debian please? The fact that
libxml2 can't migrate as-is is hurting more and more (particularly the
creation of a useful testing for riscv64).

If upstream is really reluctant to bump SONAME when they should, maybe
you should prepare for a maintenance scheme to do that in Debian when
needed. Ideally the scheme should be designed such that when upstream
bumps SONAME, you can follow them again.

Paul

[Aron Xu]

Hi,

Post by Paul Gevers
Hi Aron,

Post by Paul Gevers

Post by Aron Xu
- revert to a previous version which does not have API/ABI breakage
- apply/port security patches on a best effort basis
- help upstream to check and fix API/ABI changes

I think all three would help, where the first one is the quickest one to
get things moving again. Given the severity of the security issue
mentioned in the changelog I think you could even consider ignoring item
number two for now, but maybe you mean going forward.

Post by Aron Xu
Or do you have any recommendations?

There is the option to do a Debian specific SONAME bump, but if the
break was not intended and might get reverted that's probably a bad
idea. And if the changes are here to stay, upstream should bump SONAME
themselves.

While the upstream bug about the soname breakage seems to have halted,
can we please get some resolution in Debian please? The fact that
libxml2 can't migrate as-is is hurting more and more (particularly the
creation of a useful testing for riscv64).
If upstream is really reluctant to bump SONAME when they should, maybe
you should prepare for a maintenance scheme to do that in Debian when
needed. Ideally the scheme should be designed such that when upstream
bumps SONAME, you can follow them again.

Thanks for pinging again!

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.
- The potential for breaking locally built software is minimal.
Although abi-compliance-checker raises many issues, most of them are
not used in the real world.
- This approach is significantly easier and safer.

I've prepared a preliminary debdiff and tested locally. What do you think?

Thanks,
Aron

[Rene Engelhard]

Hi,

Post by Aron Xu
After some research, I prefer making a t64-like transition for libxml2
- 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

[Santiago Ruano Rincón]

Hi Aron,

Thanks a lot for your work on libxml2!

Hi,
[Disclaimer: I'm not the most experienced person on transitions in the team, so
I'd like for Graham, Emilio and/or Sebastian to check if they agree with me.]
Thanks for working on this.

Post by Aron Xu
After some research, I prefer making a t64-like transition for libxml2

I'm a bit curious in how far you think this looks like a t64-like transition as
apposed to a regular c-library transition. Is it because the libraries will not
be co-installable, you don't bump SONAME and just rename the binary package
name? Even with all the work that went into the t64 transition, we're starting
to see hidden bugs [0] (although I think this can happen with any transition).

Post by Aron Xu
- 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.

That's why earlier I proposed a Debian specific SONAME, "in between" 2 and 3.
Upstream (I think) even suggested that [1].

Post by Aron Xu
- The potential for breaking locally built software is minimal.
Although abi-compliance-checker raises many issues, most of them are
not used in the real world.

Isn't the fact that we *caught* an issue in Debian the proof that it's not just
academic?

Post by Aron Xu
- This approach is significantly easier and safer.

I'm hesitant because we have well established procedures to handle ABI breakage
with SONAME bumps and how to handle them in Debian. Can you elaborate on the
easier and safer parts? Because I mostly see risks to deviate from established
paths as the corner cases on them are less known.

I feel like the proposed change by Aron is the best course of action. The
benefits are that we get everything rebuilt against the new package, effectively
avoiding any issues with the ABI breaks inside Debian. And by maintaining the
same SONAME as upstream, if a user installs a binary provided by a 3rd-party,
then it will just work (assuming it was built for the newer releases or is not
affected by the ABI breaks). The drawbacks are that the old and new packages
won't be co-installable due to the file conflicts, and so the transition will
have to happen in lockstep. It will also make it harder for apt to do the
dist-upgrades from bookworm to trixie, which adds up to the t64 and possibly the
usr-merge changes.
Obviously there's an even better solution, which is for upstream to revert the
ABI break (if possible) or bump the SOVERSION, but unfortunately that seems to
be out of the picture.

I've uploaded the debdiff to experimental, and the package should hit NEW soon.
Thanks,
Aron

May I ask you what are you plans for libxml2 > 2.9.x?

The transition freeze is approaching (2025-03-15), and I would guess
that packaging 2.13.x is too disruptive for trixie right now. Please,
correct me if I am wrong! I would just like to document what are the
expectations regarding the libxml2 version to be shipped with the new
release.


For a little bit of context, I am taking a look at the packages that
have some CVEs open in unstable, and/or for which there is a new
upstream version available, from an LTS perspective. This is with the
idea of making it easier to provide security support for them thorough
the full five years of the life cycle. If you want or need help, please
don't hesitate to speak up. Someone from the LTS team may step up to
help (CC'ing the LTS team).

Cheers,

-- Santiago

P.S. The git repository is out-of-date. Would you mind importing and
pushing the latest changes?

[Aron Xu]

Hi,

Post by Paul Gevers
Hi Aron,
Thanks a lot for your work on libxml2!

Hi,
[Disclaimer: I'm not the most experienced person on transitions in

the team, so

I'd like for Graham, Emilio and/or Sebastian to check if they agree

with me.]

Thanks for working on this.

Post by Aron Xu
After some research, I prefer making a t64-like transition for

libxml2

I'm a bit curious in how far you think this looks like a t64-like

transition as

apposed to a regular c-library transition. Is it because the

libraries will not

be co-installable, you don't bump SONAME and just rename the binary

package

name? Even with all the work that went into the t64 transition,

we're starting

to see hidden bugs [0] (although I think this can happen with any

transition).

Post by Aron Xu
- Upstream is not prepared to bump the SONAME to something like
libxml3. Given the long history of this function library,

determining

Post by Aron Xu
which APIs should be public and which should be private is
challenging.

That's why earlier I proposed a Debian specific SONAME, "in between"

2 and 3.

Upstream (I think) even suggested that [1].

Post by Aron Xu
- The potential for breaking locally built software is minimal.
Although abi-compliance-checker raises many issues, most of them are
not used in the real world.

Isn't the fact that we *caught* an issue in Debian the proof that

it's not just

academic?

Post by Aron Xu
- This approach is significantly easier and safer.

I'm hesitant because we have well established procedures to handle

ABI breakage

with SONAME bumps and how to handle them in Debian. Can you

elaborate on the

easier and safer parts? Because I mostly see risks to deviate from

established

paths as the corner cases on them are less known.

I feel like the proposed change by Aron is the best course of action.

The

benefits are that we get everything rebuilt against the new package,

effectively

avoiding any issues with the ABI breaks inside Debian. And by

maintaining the

same SONAME as upstream, if a user installs a binary provided by a

3rd-party,

then it will just work (assuming it was built for the newer releases

or is not

affected by the ABI breaks). The drawbacks are that the old and new

packages

won't be co-installable due to the file conflicts, and so the

transition will

have to happen in lockstep. It will also make it harder for apt to do

the

dist-upgrades from bookworm to trixie, which adds up to the t64 and

possibly the

usr-merge changes.
Obviously there's an even better solution, which is for upstream to

revert the

ABI break (if possible) or bump the SOVERSION, but unfortunately that

seems to

be out of the picture.

I've uploaded the debdiff to experimental, and the package should hit

NEW soon.

Thanks,
Aron

May I ask you what are you plans for libxml2 > 2.9.x?
The transition freeze is approaching (2025-03-15), and I would guess
that packaging 2.13.x is too disruptive for trixie right now. Please,
correct me if I am wrong! I would just like to document what are the
expectations regarding the libxml2 version to be shipped with the new
release.
For a little bit of context, I am taking a look at the packages that
have some CVEs open in unstable, and/or for which there is a new
upstream version available, from an LTS perspective. This is with the
idea of making it easier to provide security support for them thorough
the full five years of the life cycle. If you want or need help, please
don't hesitate to speak up. Someone from the LTS team may step up to
help (CC'ing the LTS team).

Upstream promised to release 2.14 (with SONAME bumped) soon, and he just
replied to your comment on GNOME gitlab that his latest plan is February.
Let's hold breath for that and try to coordinate a transition if that
happens... or if that fails (not release in time or too hard to transition)
let's start maintain our branch of 2.9.x to include as many as fixes
possible.

Thanks for taking care!

Aron

[Santiago Ruano Rincón]

Hi!

Post by Aron Xu

Hi,
[Disclaimer: I'm not the most experienced person on transitions in

the team, so

I'd like for Graham, Emilio and/or Sebastian to check if they agree

with me.]

Thanks for working on this.

Post by Aron Xu
After some research, I prefer making a t64-like transition for

libxml2

I'm a bit curious in how far you think this looks like a t64-like

transition as

apposed to a regular c-library transition. Is it because the

libraries will not

be co-installable, you don't bump SONAME and just rename the binary

package

name? Even with all the work that went into the t64 transition,

we're starting

to see hidden bugs [0] (although I think this can happen with any

transition).

Post by Aron Xu
- Upstream is not prepared to bump the SONAME to something like
libxml3. Given the long history of this function library,

determining

Post by Aron Xu
which APIs should be public and which should be private is
challenging.

That's why earlier I proposed a Debian specific SONAME, "in between"

2 and 3.

Upstream (I think) even suggested that [1].

Post by Aron Xu
- The potential for breaking locally built software is minimal.
Although abi-compliance-checker raises many issues, most of them are
not used in the real world.

Isn't the fact that we *caught* an issue in Debian the proof that

it's not just

academic?

Post by Aron Xu
- This approach is significantly easier and safer.

I'm hesitant because we have well established procedures to handle

ABI breakage

with SONAME bumps and how to handle them in Debian. Can you

elaborate on the

easier and safer parts? Because I mostly see risks to deviate from

established

paths as the corner cases on them are less known.

I feel like the proposed change by Aron is the best course of action.

The

benefits are that we get everything rebuilt against the new package,

effectively

avoiding any issues with the ABI breaks inside Debian. And by

maintaining the

same SONAME as upstream, if a user installs a binary provided by a

3rd-party,

then it will just work (assuming it was built for the newer releases

or is not

affected by the ABI breaks). The drawbacks are that the old and new

packages

won't be co-installable due to the file conflicts, and so the

transition will

have to happen in lockstep. It will also make it harder for apt to do

the

dist-upgrades from bookworm to trixie, which adds up to the t64 and

possibly the

usr-merge changes.
Obviously there's an even better solution, which is for upstream to

revert the

ABI break (if possible) or bump the SOVERSION, but unfortunately that

seems to

be out of the picture.

I've uploaded the debdiff to experimental, and the package should hit

NEW soon.

Thanks,
Aron

May I ask you what are you plans for libxml2 > 2.9.x?
The transition freeze is approaching (2025-03-15), and I would guess
that packaging 2.13.x is too disruptive for trixie right now. Please,
correct me if I am wrong! I would just like to document what are the
expectations regarding the libxml2 version to be shipped with the new
release.
For a little bit of context, I am taking a look at the packages that
have some CVEs open in unstable, and/or for which there is a new
upstream version available, from an LTS perspective. This is with the
idea of making it easier to provide security support for them thorough
the full five years of the life cycle. If you want or need help, please
don't hesitate to speak up. Someone from the LTS team may step up to
help (CC'ing the LTS team).

Upstream promised to release 2.14 (with SONAME bumped) soon, and he just
replied to your comment on GNOME gitlab that his latest plan is February.
Let's hold breath for that and try to coordinate a transition if that
happens... or if that fails (not release in time or too hard to transition)
let's start maintain our branch of 2.9.x to include as many as fixes
possible.

Yeah, let's see. I guess it also a question of balance (as always),
between having tested library and a bleeding-edge available in trixie.

In any case, when it gets released, please don't hesitate to ask if you
would like some help to test how reverse build depends gets built.

Post by Aron Xu
Thanks for taking care!

Thanks for your work!

-- S