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
signature.asc
Description: PGP signature
