AlmaLinux EL9 + PHP 7.4/8.0: compat-openssl11-devel pinned to 1.1.1k-5.el9 blocks system updates

EL9 + PHP 7.4/8.0: compat-openssl11-devel pinned to 1.1.1k-5.el9 blocks system updates and will break PHP rebuilds after AlmaLinux update to 1.1.1k-5.el9_8.6

Environment

• AlmaLinux 9, Centmin Mod 140.00beta01
• PHP 8.0.30 built via Centmin Mod (Oct 21, 2026)

Problem

AlmaLinux AppStream now ships compat-openssl11-1:1.1.1k-5.el9_8.6. Centmin Mod installs compat-openssl11-devel-1.1.1k-5.el9 from its own mirror (centminmodparts/rpms/compat-openssl11/), and no AlmaLinux repo provides that package. Because the -devel package requires the exact same version of compat-openssl11, dnf update can’t update the library:

---

Problem: cannot install both compat-openssl11-1:1.1.1k-5.el9_8.6.x86_64 from appstream and compat-openssl11-1:1.1.1k-5.el9.x86_64 from @System
- package compat-openssl11-devel-1:1.1.1k-5.el9.x86_64 from @System requires compat-openssl11 = 1:1.1.1k-5.el9, but none of the providers can be installed

Why removing the -devel package isn’t a workaround

In inc/php_configure.inc, compile_custom_curl() forces PHP_CUSTOM_CURL='y' for EL9 with PHP 7.4/8.0 (lines ~116–120). It then runs this check (lines ~135–141):

Code (Text):

if ! rpm -q compat-openssl11 compat-openssl11-devel &>/dev/null; then
   dnf install -y "${BASE}/compat-openssl11-1.1.1k-5.el9.x86_64.rpm" \
                  "${BASE}/compat-openssl11-devel-1.1.1k-5.el9.x86_64.rpm" || return 1
fi

If a user removes the -devel package and updates the library, the next PHP rebuild tries to install the older RPMs over the newer library. That fails, and the PHP build aborts. The only options for affected users are to versionlock both packages on the old version, which skips AlmaLinux’s security update, or to stop rebuilding PHP.

Suggested fixes

1. Host a compat-openssl11-devel RPM matching 1.1.1k-5.el9_8.6, and keep it in step with future AlmaLinux updates.
2. Don’t hardcode the version in the install step. If compat-openssl11 is already installed, fetch the -devel matching the installed version (rpm -q --qf '%{VERSION}-%{RELEASE}' compat-openssl11), or fail with a clear message instead of attempting a downgrade.
3. Optionally, have centmin.sh’s update routine warn when the -devel and the library are out of step.
4. Short-term mitigation: when Centmin Mod installs its compat-openssl11 RPMs, also lock both packages so dnf update doesn’t error out:

Code (Text):

   dnf versionlock add compat-openssl11 compat-openssl11-devel

This keeps PHP rebuilds working and stops the update error, but it holds back AlmaLinux’s compat-openssl11 security updates. It should be paired with fix 1 or 2, so the lock is lifted (or bumped) once a matching -devel RPM is available. Ideally centmin.sh would print a notice that these packages are locked and why.

Side observation

ldd on the built php-fpm shows libssl.so.1.1/libcrypto.so.1.1 loaded from /opt/openssl/lib, not the compat-openssl11 libraries. The system libssl.so.3/libcrypto.so.3 are loaded in the same process as well. Is that the intended linkage?