Upcoming PHP 8.2 update and introduction of legacy packages
With the release to PHP 8.2 I will introduce a new set of packages to solve most of the issues with PHP updates. There are two valid requirements: On one hand people need the latest version to use its features or to develop new applications. And on the other hand users want to run third party applications that might not yet be compatible with the latest PHP runtime. I'll make the following changes to support both use cases while still keeping the rolling release model:
The php package we already provide will be updated to 8.2 and be kept up-to-date with the latest upstream releases. php7 packages will be removed as this version is end-of-life and will no longer receive security updates.
A new set of php-legacy packages will be introduced which always provide the oldest version actively supported by upstream*. This version is usually one year behind the latest release, but still receives bug and security fixes. It will be possible to install and use this version alongside the latest php packages. The binaries and configuration path will have a suffix named "-legacy", which will require configuration changes if you want to switch between legacy and non-legacy versions. In contrast to e.g. the php7 package, this version will also follow a rolling release model and will receive minor and even major updates.
In the end this would result in the following release schedule:
php: currently 8.1 soon 8.2 December 2023: 8.3 php-legacy: currently: 8.1 December 2023: 8.2 (upstream provides security updates till December 2024; so we have some room to postpone when issues arise.)
I will provide a news item once all these changes are ready for the stable repositories.
For packaging:
I'll take care of the module rebuilds. Most modules are already compatible or at least have patches. Similar to php7 I'll make use of split packages to build a module for both PHP branches. One exception is the uwsgi plugin which is known for being a less active project. For now it would only be possible to provide it for php-legacy.
Application packages might use the virtual php-interpreter dependency which provides the minor version. As stated above switching between legacy and non-legacy versions will require user interaction. For some packages that are known for almost never being compatible with latest PHP versions, it might be easier to depend on php-legay right away.
Greetings,
Pierre
*) https://www.php.net/supported-versions.php
Hey,
On 17/12/2022 11:13, Pierre Schmitz wrote:
With the release to PHP 8.2 I will introduce a new set of packages to solve most of the issues with PHP updates. There are two valid requirements: On one hand people need the latest version to use its features or to develop new applications. And on the other hand users want to run third party applications that might not yet be compatible with the latest PHP runtime. I'll make the following changes to support both use cases while still keeping the rolling release model:
<snip>
In the end this would result in the following release schedule:
php: currently 8.1 soon 8.2 December 2023: 8.3 php-legacy: currently: 8.1 December 2023: 8.2 (upstream provides security updates till December 2024; so we have some room to postpone when issues arise.)
I don't object against providing an older PHP but why is it named php-legacy? We don't really have a policy for this, but it feels inconsistent versus the current php7, ruby2.7 package. (Ofcourse nodejs-lts-gallium is then also inconsistent but at least that is clearly named as that upstream).
Greetings,
Jelle
On Mon, Dec 19, 2022 at 3:40 PM Jelle van der Waa jelle@vdwaa.nl wrote:
I don't object against providing an older PHP but why is it named php-legacy? We don't really have a policy for this, but it feels inconsistent versus the current php7, ruby2.7 package. (Ofcourse nodejs-lts-gallium is then also inconsistent but at least that is clearly named as that upstream).
I looked for several options regarding naming and ended up with either "-old" or "-legacy". I chose the later as it has a less negative tone and there are precedence for it in naming different releases branches. We also have similar concepts with libreoffice-still and libreoffice-fresh or nginx and nginx-mainline.
Numbers couldn't be used here as both branches will get updated regularly. php-legacy will be bumped to version 8.2 and even 9.0 some day. So the difference is that I didn't want to provide a specific version but two different release branches. This makes it easier for users to update and packagers to maintain. It should be inline with Arch's rolling release model.
Greetings,
Pierre
The rebuild for modules and anything that links against PHP went quite well and I have moved the packages into [testing]. Even uwsgi did build with a simple patch. I did notice that this project is in maintenance mode according to upstream; so I am not that optimistic we can provide the PHP plugin in future. At least for PHP I highly suggest to use php-fpm instead. In general the actual breaking changes from 8.1 to 8.2 are minor. I expect most apps to work without or minimal changes; even though some of these might be quite subtile. See https://www.php.net/manual/en/migration82.incompatible.php
One of the special cases is probably nextcloud with its version check. I'd suggest to use php-legacy here is this will always point to a version that is supported by upstream.
Let me know of any issues that arise.
Greetings,
Pierre
On 2022-12-20 10:00:09 (+0100), Pierre Schmitz wrote:
The rebuild for modules and anything that links against PHP went quite well and I have moved the packages into [testing]. Even uwsgi did build with a simple patch. I did notice that this project is in maintenance mode according to upstream; so I am not that optimistic we can provide the PHP plugin in future.
Yep :( That upstream is in a sad state unfortunately.
I would be happy to see more extensive documentation on php-fpm in the wiki (and also upstream). Currently, the state of documentation is quite terrible around this (default) integration. :S
One of the special cases is probably nextcloud with its version check. I'd suggest to use php-legacy here is this will always point to a version that is supported by upstream.
Please rebuild nextcloud packages and see if they work before moving php to outside of staging. This is what I introduced the php-interpreter virtual provides for! :)
Package builds should fail right away in check() if it is not compatible. I think we will need to do an adjustment to the clamping code that Caleb introduced a while back though, as it still relies on the "php7" binary, but should instead rely on "php-legacy" instead now I guess.
Best, David
On Tue, Dec 20, 2022 at 10:12 AM David Runge dave@sleepmap.de wrote:
Please rebuild nextcloud packages and see if they work before moving php to outside of staging. This is what I introduced the php-interpreter virtual provides for! :)
Package builds should fail right away in check() if it is not compatible. I think we will need to do an adjustment to the clamping code that Caleb introduced a while back though, as it still relies on the "php7" binary, but should instead rely on "php-legacy" instead now I guess.
Good point. I only looked at the package metadata and not the PKGBUILD. This indeed needs some adjustment as it makes some assumptions that no longer work. I would propose to make it depend on php-legacy directly (but keep the version check on build and versioned dependency). This should reduce the complexity of the PKGBUILD a lot. There are only a few months every year where Nextcloud will work with the latest PHP version and users will need to adjust their configuration when moving back and forward. (I can do the required changes if you like)
Greetings,
Pierre
On Tue, Dec 20, 2022 at 10:44 AM Pierre Schmitz pierre@archlinux.de wrote:
(I can do the required changes if you like)
As some code is probably easier to talk about here is my idea in patch from: https://gist.github.com/pierres/227602544b54a1b027471b6ccdab36c1
On 2022-12-20 11:09:15 (+0100), Pierre Schmitz wrote:
On Tue, Dec 20, 2022 at 10:44 AM Pierre Schmitz pierre@archlinux.de wrote:
(I can do the required changes if you like)
As some code is probably easier to talk about here is my idea in patch from: https://gist.github.com/pierres/227602544b54a1b027471b6ccdab36c1
Hm, I'm not so happy about this removing the checks and hardcoding php-legacy though. With the current approach users can at least choose and we get more feedback during build of the package. Plus, this is supposed to work with automatic rebuilds (e.g. when bumping the interpreter(s)), which IMHO is quite desirable.
I can look into fixing it later today.
On Tue, Dec 20, 2022 at 11:25 AM David Runge dave@sleepmap.de wrote:
Hm, I'm not so happy about this removing the checks and hardcoding php-legacy though.
The check is done by calling versioncheck.php directly as it fails when version constraints are not met.
You are correct, if we want users to be able to use both PHP packages we cannot hard-code it. On the other hand, the current solution hard codes it during build time. This means users cannot switch to another compatible PHP version without rebuilding the package. We should also be aware that using this approach might unexpectedly change the dependencies. E.g. if you build nextcloud today it will depend on php-legacy. If you build it in 6 month it might depend on the regular php package. When this happens, users might need to update their php.ini, web server and systemd services configuration.
But I do not mind much; in the end its a trade-off between complexity and choice.
With the current approach users can at least choose and we get more feedback during build of the package. Plus, this is supposed to work with automatic rebuilds (e.g. when bumping the interpreter(s)), which IMHO is quite desirable.
I can look into fixing it later today.
Great, thanks.
On 2022-12-20 11:49:28 (+0100), Pierre Schmitz wrote:
On Tue, Dec 20, 2022 at 11:25 AM David Runge dave@sleepmap.de wrote:
Hm, I'm not so happy about this removing the checks and hardcoding php-legacy though.
The check is done by calling versioncheck.php directly as it fails when version constraints are not met.
You are correct, if we want users to be able to use both PHP packages we cannot hard-code it. On the other hand, the current solution hard codes it during build time. This means users cannot switch to another compatible PHP version without rebuilding the package. We should also be aware that using this approach might unexpectedly change the dependencies. E.g. if you build nextcloud today it will depend on php-legacy. If you build it in 6 month it might depend on the regular php package. When this happens, users might need to update their php.ini, web server and systemd services configuration.
But I do not mind much; in the end its a trade-off between complexity and choice.
With the current approach users can at least choose and we get more feedback during build of the package. Plus, this is supposed to work with automatic rebuilds (e.g. when bumping the interpreter(s)), which IMHO is quite desirable.
I can look into fixing it later today.
There has been a problem [1] introduced by not renaming the soname of libphp-legacy.so. The soname was still libphp.so, so linking against libphp-legacy.so led to dependents requiring libphp.so instead (this was also the case for the apache plugin btw). This should have been tested more thoroughly and it took me some time to figure out what was going wrong yesterday. A patched php-legacy is in [testing] though.
Meanwhile, there still seem to be issues with uwsgi-plugin-php-legacy and it would be great, if you could help solve them, since this is broken after switching to php-legacy.
Best, David
On 2023-01-15 12:25:36 (+0100), David Runge wrote:
There has been a problem [1] introduced by not renaming the soname of libphp-legacy.so. The soname was still libphp.so, so linking against libphp-legacy.so led to dependents requiring libphp.so instead (this was also the case for the apache plugin btw). This should have been tested more thoroughly and it took me some time to figure out what was going wrong yesterday. A patched php-legacy is in [testing] though.
Meanwhile, there still seem to be issues with uwsgi-plugin-php-legacy and it would be great, if you could help solve them, since this is broken after switching to php-legacy.
I would really appreciate if there was feedback on this issue from your side.
The move to stable was (as you mentioned yourself) a potential breaking change. Doing this on a Friday and then not being available to fix potential breakage is not cool. Currently everyone relying on uwsgi + php-legacy is affected by this.
Best, David
Ill look into this. Unfortunately this slipped through as I did only use the cli and fpm sapis. Bug thanks for providing the patch! I have seen others use the patchelf tool to rewrite the sonames. I'll check if that would make the solution more reliable.
On Sun, Jan 15, 2023 at 12:25 PM David Runge dave@sleepmap.de wrote:
On 2022-12-20 11:49:28 (+0100), Pierre Schmitz wrote:
On Tue, Dec 20, 2022 at 11:25 AM David Runge dave@sleepmap.de wrote:
Hm, I'm not so happy about this removing the checks and hardcoding php-legacy though.
The check is done by calling versioncheck.php directly as it fails when version constraints are not met.
You are correct, if we want users to be able to use both PHP packages we cannot hard-code it. On the other hand, the current solution hard codes it during build time. This means users cannot switch to another compatible PHP version without rebuilding the package. We should also be aware that using this approach might unexpectedly change the dependencies. E.g. if you build nextcloud today it will depend on php-legacy. If you build it in 6 month it might depend on the regular php package. When this happens, users might need to update their php.ini, web server and systemd services configuration.
But I do not mind much; in the end its a trade-off between complexity and choice.
With the current approach users can at least choose and we get more feedback during build of the package. Plus, this is supposed to work with automatic rebuilds (e.g. when bumping the interpreter(s)), which IMHO is quite desirable.
I can look into fixing it later today.
There has been a problem [1] introduced by not renaming the soname of libphp-legacy.so. The soname was still libphp.so, so linking against libphp-legacy.so led to dependents requiring libphp.so instead (this was also the case for the apache plugin btw). This should have been tested more thoroughly and it took me some time to figure out what was going wrong yesterday. A patched php-legacy is in [testing] though.
Meanwhile, there still seem to be issues with uwsgi-plugin-php-legacy and it would be great, if you could help solve them, since this is broken after switching to php-legacy.
Best, David
participants (3)
-
David Runge
-
Jelle van der Waa
-
Pierre Schmitz