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 <d...@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 <d...@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 > > > [1] https://bugs.archlinux.org/task/77124 > > -- > https://sleepmap.de -- Pierre Schmitz, https://pierre-schmitz.com
