[arch-dev-public] Upcoming PHP 8.1 update

[Pierre Schmitz]

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)

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.

The "-interpreter" suffix is required to make it work with pacman or
could php-legacy-apcu provide php-apcu=7.4?

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.

Greetings,

Pierre

On Sun, Apr 24, 2022 at 6:57 PM David Runge <dave at sleepmap.de> wrote:
>
> On 2022-03-08 13:56:04 (+0100), David Runge via arch-dev-public wrote:
> > after waiting another couple of weeks, the situation with nextcloud
> > unfortunately has still not improved.
> > We see issues with utf-8 compatibility [1] and meanwhile the version
> > 24.0.0 which is supposed to provide native support for php 8.1 is being
> > delayed until end of April [2].
> >
> > This all being what it is, I believe the sanest (but also a bit
> > complicated to maneuvre) way forward is to downgrade its dependencies to
> > php7, as otherwise we will be stuck even longer with
> > broken/disfunctional setups.
>
> Meanwhile more time has passed and there has not been any progress on
> this. For nextcloud 23.0.4 the compatibility patches do not apply
> cleanly anymore.
>
> Therefore I will implement a specific version check for it to check its
> own php compatibility and fail otherwise, while removing the patches.
>
> > The version constraints are implemented directly towards the language
> > version the application is run with and would mean a good safe-guard
> > against breakage in packaging and expectation.
> > As it stands we would need to add a provides php=$version to the "older"
> > php package (this also needs to be done for the current php7), which
> > would allow more or less seamless upgrades/downgrades based upon the
> > requirements of a given project. By default projects would always use
> > the latest php, if not declaring version requirements.
> > An upgrade to a given project, introducing an updated php version
> > requirement, would automatically pull in the required php* package.
> >
> > I'm still a bit unsure about how to deal with this in the context of php
> > modules though. For those we would still need to specifically touch a
> > given PKGBUILD to change a dependency (e.g. php-gd vs. php7-gd) unless
> > we come up with a way to abstract this with a common virtual provides.
>
> I will introduce this for php7 in [testing] now and build nextcloud
> 23.0.4 against it.
>
> This works for the interpreter, but it's more involved when looking at
> the remaining interpreter-specific modules.
>
> It would make sense to implement an abstraction for each that pulls in
> the correct package.
> E.g. for php7-apcu add a `provides=(php-apcu-interpreter=7)` and for
> php-apcu add a `provides=(php-apcu-interpreter=8)`.
> That way consumers can decide which interpreter they require by
> depending on e.g. `php-apcu-interpreter=8`. This works similar to how we
> do things for java.
>
> Do you have any thoughts on this?
>
> Best,
> David
>
> --
> https://sleepmap.de



-- 
Pierre Schmitz, https://pierre-schmitz.com