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

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

On Tue, Dec 20, 2022 at 10:12 AM David Runge 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 -- Pierre Schmitz, https://pierre-schmitz.com

On 2022-12-20 11:09:15 (+0100), Pierre Schmitz wrote:

On Tue, Dec 20, 2022 at 10:44 AM Pierre Schmitz 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. -- https://sleepmap.de

On 2022-12-20 11:49:28 (+0100), Pierre Schmitz wrote:

On Tue, Dec 20, 2022 at 11:25 AM David Runge 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 [1] https://bugs.archlinux.org/task/77124 -- https://sleepmap.de

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 wrote:

On 2022-12-20 11:49:28 (+0100), Pierre Schmitz wrote:

...

On Tue, Dec 20, 2022 at 11:25 AM David Runge 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

[1] https://bugs.archlinux.org/task/77124

-- https://sleepmap.de

-- Pierre Schmitz, https://pierre-schmitz.com