Automatic reset of /etc/alternatives/php with multiple PHP versions

My YunoHost server

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.

By using

ln -sfn /usr/bin/php8.2 php

or (supposedly permanently) using

sudo update-alternatives --set php /usr/bin/php8.2

the link can be set to version 8.2.

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 …

To me the real issue is :

These should source an explicit X.Y php version …

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.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.