[arch-dev-public] Upcoming PHP 8.1 update

[David Runge]

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
-------------- 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/20220424/8272617c/attachment.sig>