Comment 1 for bug 2018100

Revision history for this message
Athos Ribeiro (athos-ribeiro) wrote :

The current Ubuntu delta reduced the Breaks minimal version for some PECL extensions to account for the state of the Ubuntu archive back during the PHP 8.1 transition. They were

- Debian
+ Ubuntu

- php-facedetect (<< 1.1.0-19-g135c72a-10~),
+ php-facedetect (<< 1.1.0-19-g135c72a-2build3~),

- php-libvirt-php (<< 0.5.5-16~),
+ php-libvirt-php (<< 0.5.5-3ubuntu2~),

- php-tideways (<< 5.0.4-13~),
+ php-tideways (<< 5.0.4-2build3~),

- php-xmlrpc (<< 3:1.0.0~rc3-4~),
+ php-xmlrpc (<< 3:1.0.0~rc3-2~),

with exception of php-facedetect, all the other PECL extensions in mantic are in versions greater than the Debian Breaks targets, which makes it safe for us to sync the package (except for php-facedetect).

However, php-facedetect has been broken for a while (see LP: #1951812, #1995628). The current mantic package is installable, but does not contain the shared object it was supposed to ship, resulting in a broken package.

1.1.0-19-g135c72a-10 is supposed to fix the issues, but the package hasn't been uploaded in Debian for a while now (https://salsa.debian.org/php-team/pecl/php-facedetect/-/blob/debian/main/debian/changelog#L43).

Therefore, we can either:

1) merge php-defaults, keeping the "php-facedetect (<< 1.1.0-19-g135c72a-2build3~)" Breaks entry. This way php-facedetect will still be installable and we can work on fixing it after the 8.2 transition is complete;

2) sync php-defaults with php-facedetect as is. This will make php-facedetect uninstallable. We can then either fix it or get it removed from the archive for mantic (so far, it is not making it into the next Debian release either).

3) Remove php-facedetect from the archive and only then sync php-defaults.

4) Fix php-facedetect and only then sync (or merge, depending on the facedetect fixed version) php-defaults.

For now, I am inclined to go with (2). (1) would leave lots of space for allowing php-facedetect to fall behind and remain broken. (3) can just be deferred if we go with (2). (4) could add extra work since there is a chance we may need to fix the package twice (for php8.1 and then for php8.2).

Thoughts?