On 2022-04-24 19:08:37 (+0200), Pierre Schmitz via arch-dev-public wrote:
I'd still suggest to provide two different php versions as mentioned some time ago: the current "php" and "php-legacy" which will always be the oldest supported version. These may provide the versions as you suggested: php-legacy provides php=7.4 (and will be updated to 8.0 soon)
What would be the name of the executable provided by the old php package? If it stayed the same that could be nice (less things to change).
I'd probably change the package name from php-legacy to something else (e.g. php-old or php-lts).
The benefit of not encoding the versions within the package name is easier maintenance and user wont have to manually update their config and systemd files.
Do you mean this also in regards to executable naming? Because that would indeed be more stable then (although less specific of course). It could prove useful to provide compat symlinks.
The "-interpreter" suffix is required to make it work with pacman or could php-legacy-apcu provide php-apcu=7.4?
The "-interpreter" suffix for the package provides would only be relevant for packages depending on e.g. a specific interpreter version. That way e.g. an optional dependency on php-apcu-interpreter<8.1 could be used by nextcloud to depend on a php-apcu provider which supports a php interpreter < 8.1 (in this case php7-apcu would match).
The only downside to this scenario is, that we need to rebuild all php module packages when updating minor versions of php (e.g. from 8.0 -> 8.1) so that the respective packages are rebuilt and pickup the correct version they now provide.
On a side node: PHP 7 is on its way out of support and wont work with e.g. OpenSSL 3 :-) So we have to update to 8.0 in a few month at latest.
That's okay and I hope nextcloud is updated by then to support it.