On 2022-04-24 21:13:43 (+0200), David Runge via arch-dev-public wrote:
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.
One further downside of the "-interpreter" approach is, that it is terrible in optdepends, as we can't specify a range (e.g. foo-interpreter>=7.4 and foo-interpreter<8.1) in one optdepends entry :S Other than that, it might provide better stability going forward, but we would still need to ensure to rebuild the entire lot when updating minor versions of the interpreter (which I think is still an okay outcome). And a note on the versioned provides (e.g. `php-apcu=7.4` for the current php7-apcu). I believe this should be done, but it would only prove useful if packagers then relied on two dependency contraints (I'm choosing a different module, because php-apcu has always the same version as the interpreter): Depend on e.g. php-igbinary>3.2 and php-igbinary-interpreter=7.4 (this way php7-igbinary, when following the current naming scheme, would be selected). Once again, rebuilds **have to** be done on minor version interpreter updates, else this does not work. What do you think? Best, David -- https://sleepmap.de