[arch-dev-public] Upcoming PHP 8.1 update

David Runge dave at sleepmap.de
Tue Mar 8 12:56:04 UTC 2022

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.


[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

-------------- 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/20220308/d6de21a0/attachment.sig>

More information about the arch-dev-public mailing list