[pkg-php-pear] Bug#976811: Bug#976811: transition: php8.1

[Ondřej Surý]

> On 1. 1. 2022, at 9:01, Paul Gevers <elbrus at debian.org> wrote:
> 
> Hi,
> 
> On 31-12-2021 21:25, Paul Gevers wrote:
>> Hi Ondřej, PHP PECL Maintainers,
>> On 31-12-2021 12:50, Ondřej Surý wrote:
>>> Uploaded php 8.1.1 and php-defaults 91 switching the Debian PHP version to PHP 8.1
>> Thanks.
>> Will you also upload src:php-imagick, which seems to block some rebuilds in the current state.
>> I want to update the ben transition tracker file to catch these kind of packages. Should I add a "Depends on php7.4-common" to the "bad" list?
> 
> It seems I don't understand how PHP packaging works. I scheduled rebuilds of several packages that were yesterday on the tracker page [1] when that still only had the phpapi-* listed. Several packages can't be build yet it seems (because they depend on packages that need new uploads), but e.g. wikidiff2 built fine *but disappeared* from the tracker. I looked at a build log [2] and noticed that the binary has files in /etc/php8.1 (and not in /etc/php7.4), but doesn't tell otherwise (in package relations) that it's meant for php8.1 and not for php7.4. Why did that phpapi-* thing disappear? Is that intended? The built binaries already migrated to testing, while the default there is still php7.4. I assume we can consider php-wikidiff2 (partially?) broken now *in testing*? Same for php-luasandbox [3], php-geos [4], and php-excimer [5] (which also FTBFS on mipsel).

This has been tracker as #1000233 and hopefully fixed in dh-php 4.4

> Some rebuilds failed, e.g. php-horde-lz4 [6],

The FTBFS is unrelated to PHP 8.1 transition

> php-wmerrors [7], owfs [8].

These two need upstream update.

> I also notice that quite some php packages grew a php7.4-* package in unstable. Is the idea that that needs to be done for php8.1 too and that all those packages require a round trip through NEW? If that's the case, next time please prepare those in experimental, such that we don't need to wait for processing of NEW during the transition. If that's not the case, please upload new versions of those packages dropping the php7.4 package.

Yes, I rewrote the helper scripts for PECL based packages, and I haven’t realized this. The idea is to align the embedded extensions schema[a] with the externally (PECL) distributed extensions. This is bit tricky though, I was faced with two options:

1. Add all binary packages to debian/control directly and do the NEW queue
2. Generate all binary packages to debian/control during the build, but this would then require overrides (which I think doesn’t really scale)

> Please enlighten me on the details of php packaging that I'm missing and that we should be aware of for this (and future) transition(s).

Currently, there are two types:

1. arch:any php-<name> that contains the extension and the configuration - uses whatever build system is there
2. arch:all php-<name> depending on arch:any phpX.Y-<name> that uses /usr/share/dh-php/pkg-pecl.mk Makefile snippet which does a lot of “magic”, but so is a bit fragile as everything that is “magic” is.

Ondrej

a. Arch: any package php<maj>.<min>-<ext> and Arch: all  package php-<ext> that depend on it
--
Ondřej Surý (He/Him)
ondrej at sury.org

> Paul
> 
> [1] https://release.debian.org/transitions/html/php8.1.html
> [2] https://buildd.debian.org/status/fetch.php?pkg=wikidiff2&arch=amd64&ver=1.13.0-1%2Bb1&stamp=1640981156&raw=0
> [3] https://buildd.debian.org/status/package.php?p=php-luasandbox
> [4] https://buildd.debian.org/status/package.php?p=php-geos
> [5] https://buildd.debian.org/status/package.php?p=php-excimer
> [6] https://buildd.debian.org/status/package.php?p=php-horde-lz4
> [7] https://buildd.debian.org/status/package.php?p=php-wmerrors
> [8] https://buildd.debian.org/status/package.php?p=owfs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://alioth-lists.debian.net/pipermail/pkg-php-pear/attachments/20220101/aac93bc5/attachment.sig>