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
signature.asc
Description: PGP signature
