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@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
-- Pierre Schmitz, https://pierre-schmitz.com