On 2022-12-20 11:49:28 (+0100), Pierre Schmitz wrote:
On Tue, Dec 20, 2022 at 11:25 AM David Runge email@example.com 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  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.