I received, via Virtualmin, the system updates for PHP 8.1 that I have tried to install previously a few times, but could not.
Just in case, I would like to solve this problem to allow other installations, such as Django that requires it.
Below was the result of the last installation attempt. I conclude that PHP 8.1 is already installed on my system although not active.
Last metadata expiration check: 1:10:06 ago on Mon Jul 24 19:29:49 2023.
Error:
Problem 1: problem with installed package php-pecl-ssh2-1.4-1.el9.x86_64
package php-pecl-ssh2-1.4-1.el9.x86_64 requires php(api) = 20200930-64, but none of the providers can be installed
package php-pecl-ssh2-1.4-1.el9.x86_64 requires php(zend-abi) = 20200930-64, but none of the providers can be installed
cannot install both php-common-8.1.14-1.module_el9.2.0+24+ca6bd7c2.x86_64 and php-common-8.0.27-1.el9_1.x86_64
cannot install the best update candidate for package php-common-8.0.27-1.el9_1.x86_64
package php-common-8.0.27-1.el9_1.x86_64 is filtered out by modular filtering
package php-common-8.0.28-4.el9.remi.x86_64 is filtered out by modular filtering
package php-common-8.0.29-1.el9.remi.x86_64 is filtered out by modular filtering
Problem 2: problem with installed package php-pecl-imagick-3.7.0-1.el9.x86_64
package php-pecl-imagick-3.7.0-1.el9.x86_64 requires php(api) = 20200930-64, but none of the providers can be installed
package php-pecl-imagick-3.7.0-1.el9.x86_64 requires php(zend-abi) = 20200930-64, but none of the providers can be installed
cannot install both php-common-8.1.14-1.module_el9.2.0+24+ca6bd7c2.x86_64 and php-common-8.0.27-1.el9_1.x86_64
package php-cli-8.1.14-1.module_el9.2.0+24+ca6bd7c2.x86_64 requires php-common(x86-64) = 8.1.14-1.module_el9.2.0+24+ca6bd7c2, but none of the providers can be installed
cannot install the best update candidate for package php-cli-8.0.27-1.el9_1.x86_64
package php-common-8.0.27-1.el9_1.x86_64 is filtered out by modular filtering
package php-common-8.0.28-4.el9.remi.x86_64 is filtered out by modular filtering
package php-common-8.0.29-1.el9.remi.x86_64 is filtered out by modular filtering
(try to add ‘–allowerasing’ to command line to replace conflicting packages or ‘–skip-broken’ to skip uninstallable packages or ‘–nobest’ to use not only best candidate packages)
(1-) Remove and reinstall the remi package?
(2-) Remove only what doesn’t fit the system?
I followed the guidelines on this page that you mentioned.
In this guide there are two steps to effect the installation.
The first step the system returns me as already installed.
When I go to the 2nd step, install php 8.1, the system returns the above information.
I believe I have to remove something.
This may have happened due to interruption or reduction in internet connection but, I’m not sure.
So I thought I could remove remi repo to reinstall it
This command may (but may not, I can’t find the details of that particular module) install mod_php.
If it does, that’d be a bad thing.
Hopefully it doesn’t. Modules are so new that I kinda doubt whoever specified them would have made mod_php a first class citizen for the PHP module, I would hope not. I think it’s an accident of history that it’s the first dependency in the Debian/Ubuntu metapackages and in the package named php (or php8.1 or whatever).
I’ll try to test when I get some free time, but for the time being, I still recommend folks follow our documentation. Our documentation does not tell you to install the php:8.1/common module.
I have run deeper tests on the latest Rocky 9.2, and installing PHP with dnf module command actually works! I also tested it with different PHP versions installed from Remi – which also worked just fine. I’m sorry — I was wrong before!
Although, I remember that in the past it certainly broke things! I’m still not certain if that would work on the older RHEL systems (and its derivates). We may change documentation in the future to include dnf module but before that, I would suggest to refrain from recommending it, as it hasn’t been tested fully yet.
module php is not the same as php the package (which contains mod_php on RPM-based systems, and depends on mod_php in deb-based systems). Modules are new, and I guess a new take on groups or metapackges.
