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