[arch-dev-public] Upcoming PHP 8.1 update

[David Runge]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20220425/5619e631/attachment.sig>