Hardware: VPS bought online YunoHost version: 11.2.28 (stabe) I have access to my server : Through SSH | through the webadmin Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : no
Description of my issue
Versions 7.4, 8.0 and 8.2 of PHP are installed on my server.
Some of my apps require version 8.2. All other apps either work with version 8.2 without problems or they set the version themselves.
My Hubzilla installation (as my_webapp, not as YunoHost app) and my (streams) installation (as YunoHost app) use the PHP version via shebang/env in certain scripts, which is why they use the system-wide default version as defined in /etc/alternatives.
But after every update of the YunoHost system (package) or a PHP update at the latest, the link is bent back to 7.2.
Is it possible to prevent the version from being changed via a link from /etc/alternatives/php during updates? I was of the opinion that the method with update-alternatives would prevent a reset. But even after the last YunoHost update it was back to 7.2, which I noticed by misbehaviour of (streams) and Hubzilla and had to fix the problems by changing to 8.2 again.
Not really… It’s somewhat coded somewhere that this should point to the version shipped in Debian stable
I suppose it should, but somehow running apt install phpX.Y-stuff makes it point to phpX.Y so that defeats whatever purpose it was designed for idk
To me no software should point to just “php” and always use an explicit “phpX.Y” considering the fact that just “php” is ambiguous in the context of YunoHost …
This must be a YonuHost mechanism, because on my other VPS, on which no YH is running, the alternative version is not reset under Debian (11).
I agree with you on that. Basically, it’s the same with both systems. When installing, you configure the php version in the .htconfig file:
// Location of PHP command line processor
App::$config['system']['php_path'] = '/usr/bin/php8.2';
This means that the system always uses the correct interpreter. However, there are a few scripts that are also called (can be called) independently of the app server, which do not (cannot?) fall back on this configuration and call php via shebang.
These are things that need to be improved/corrected.