Hi again, 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.
I agree this should be the way to go. Not sure if I get your right here, but (extensive) testing is best done by upstream projects though. And a lot of them even test with release candidates so their releases even work on day one. I usually provide release candidates for Arch's PHP packages as well. I could make that more public for maintainers that want to test as early as possible. We might also ask packagers to run basic unit tests during packaging.
In our packaging use-case it already fails in the most basic ways when looking at nextcloud and the nextcloud apps. Some apps at this point are still not or have up to recently not been compatible with php 8.1 (e.g. nextcloud-app-calendar [1], nextcloud-app-notes [2] and some apps in the store, e.g. providing TOTP), rendering nextcloud disfunctional. We need more check() implementations in the app PKGBUILDs that also test for the php requirement (those are encoded in the apps) and fail when trying to build against a php version that is not supported. As an example: For the app compatibility towards nextcloud (server) we are automatically creating lower and upper version boundaries by now and this usually works out fine and provides a much safer upgrade scenario than before. The same needs to happen for the apps, as they will fail to load outside of their support window.
They would be installable and usable at the same time. In the same we as you may currently use PHP 7 and 8, which was originally meant to be a temporary solution. There is a catch though: The user has to alter the configuration when he wants to switch versions.
Could you elaborate a bit further on what you mean by that? How would namespacing of that "older" php version look like specifically? How and why would this differ from the way we currently provide e.g. php7 (and potentially a php80 or similar)?
This is likely exaggerated. Adaption of new versions is quite fast these days, especially minor ones. Most of the frameworks, packages and libraries had compatible release before the first patch release. But of course this heavily depends on what you work with. And here is the whole point of the issue: On one hand people want or need the latest packages and on the other hand some projects might need more time.
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.
This might be true and as we have some packages with dead upstream projects this is even likely. The only option would be to remove such packages from our repositories then. I wouldn't want to provide PHP packages that do not receive any upstream security fixes anymore. This might sound harsher as it actually is as this would mean packages did not manage to work with PHP versions released two years ago.
Projects that fall out of the window of what we can support should indeed be removed.
I would hope this would break less as we would depend such packages to PHP versions that are actually supported by the upstream projects. As an example: As we now know that Nextcloud usually needs some more time we would suggest to install php-legacy. Packages like WordPress or phpMyAdmin could depend on the latest php packages as these are usually compatible.
I would try to handle this entirely with version constraints in the given leaf packages, similar to how we do this with java environments. Best, David [1] https://github.com/nextcloud/server/issues/31212 [2] https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule [3] https://bugs.archlinux.org/task/74016 [4] https://bugs.archlinux.org/task/73930 -- https://sleepmap.de