Sign in Subscribe
cpanel

How to Fix AlmaLinux 8 DNF Perl Module Conflicts on cPanel Servers

Nestict Infotech CSR

Nestict Infotech CSR

— 6 min read
Share
How to Fix AlmaLinux 8 DNF Perl Module Conflicts on cPanel Servers

Troubleshooting Guide: Perl 5.26, Net-SNMP, EA-PHP SNMP and AppStream Modular Filtering

Updating an AlmaLinux 8 server can occasionally produce a confusing series of dependency errors involving Perl, net-snmp, PHP SNMP extensions and AppStream module streams.

A typical example is:

cannot install both perl-libs-4:5.32.1-473...
and perl-libs-4:5.26.3-423.el8_10.1...

followed by errors such as:

net-snmp requires libperl.so.5.26

and:

package ea-php83-php-snmp ... requires net-snmp,
but none of the providers can be installed

This guide explains how to diagnose the problem safely on an AlmaLinux 8/cPanel server without unnecessarily removing Perl, Net-SNMP or cPanel's EasyApache packages.

1. Understanding the Problem

The apparent problem may look like a PHP problem because the transaction reports packages such as:

ea-php82-php-snmp
ea-php83-php-snmp

However, these packages are usually only downstream victims of the dependency conflict.

The dependency chain is approximately:

EA-PHP SNMP
     │
     ▼
  net-snmp
     │
     ▼
libperl.so.5.26
     │
     ▼
 Perl 5.26

The important requirement is:

net-snmp requires libperl.so.5.26()(64bit)

Therefore, replacing the system Perl 5.26 packages with Perl 5.32 is not an appropriate first response.

2. The Critical Error

The most important part of the DNF transaction is usually similar to:

cannot install both perl-libs-4:5.32.1-473...
from appstream

and

perl-libs-4:5.26.3-423.el8_10.1...
from @System

The system may also report:

package perl-libs-4:5.26.3-423.el8_10.1
from baseos is filtered out by modular filtering

This indicates that DNF is attempting to resolve packages across incompatible Perl module streams.

For example, AlmaLinux 8 AppStream can expose:

perl 5.24
perl 5.26
perl 5.30
perl 5.32

But a server does not normally use all of these simultaneously.

On the affected server, the correct enabled stream was:

perl 5.26 [d][e]

where:

  • [d] = default
  • [e] = enabled

3. Do Not Immediately Remove Perl

One of the biggest mistakes when encountering this problem is attempting to solve it by removing Perl or changing the Perl stream blindly.

For example, avoid immediately running:

dnf remove perl

or:

dnf module enable perl:5.32

Also avoid blindly using:

dnf update --allowerasing

The reason is that other system packages can depend on the Perl ABI currently installed.

In the affected system, net-snmp specifically required:

libperl.so.5.26

Changing the system Perl stream could therefore create additional dependency problems.

4. Check the Installed Perl Packages

Start by checking the actual packages installed on the server:

rpm -q perl perl-libs net-snmp

A healthy result for the affected system was:

perl-5.26.3-423.el8_10.1.x86_64
perl-libs-5.26.3-423.el8_10.1.x86_64
net-snmp-5.8-33.el8_10.x86_64

This immediately tells you that the server is using the Perl 5.26 ABI required by net-snmp.

5. Check the Perl Module Stream

Next run:

dnf module list perl

The relevant section should look similar to:

Name  Stream       Profiles                    Summary
perl  5.24         common [d], minimal         Practical Extraction...
perl  5.26 [d][e]  common [d], minimal         Practical Extraction...
perl  5.30         common [d], minimal         Practical Extraction...
perl  5.32         common [d], minimal         Practical Extraction...

The important indicator is:

5.26 [d][e]

This means Perl 5.26 is both the default and enabled stream.

If the installed system Perl is 5.26.3 and net-snmp requires libperl.so.5.26, this is the stream you generally want to preserve.

6. Refresh DNF Metadata

Before making destructive package changes, refresh the DNF metadata:

dnf makecache

This is particularly important when the repository metadata or module metadata is temporarily inconsistent.

In the affected case, refreshing the metadata was sufficient to restore correct dependency resolution.

After the cache refresh, run:

dnf update --assumeno

The --assumeno option is useful because it resolves the transaction without actually applying it.

A clean result is:

Dependencies resolved.
Nothing to do.
Complete!

This means DNF no longer has a pending transaction requiring package changes.

7. Run a Dependency Check

Once DNF resolves correctly, run:

dnf check

A healthy result should indicate that there are no dependency problems.

This is preferable to forcing package replacements simply because the original update command produced a large dependency error.

8. Why EA-PHP SNMP Appears in the Error

cPanel's EasyApache packages may contain SNMP support such as:

ea-php82-php-snmp
ea-php83-php-snmp

These packages depend on:

net-snmp

The dependency relationship looks like this:

ea-php82-php-snmp
        │
        ▼
     net-snmp
        │
        ▼
 libperl.so.5.26
        │
        ▼
 perl-libs 5.26.3

Therefore, an error involving:

ea-php82-php-snmp

does not necessarily mean the EasyApache PHP installation is broken.

The underlying issue can be the Perl module stream.

9. Understanding "Modular Filtering"

The phrase:

filtered out by modular filtering

is important.

AlmaLinux 8 uses modular repositories for some packages. A package can exist in the repository but still be unavailable to DNF because the currently selected module stream filters it out.

For example, DNF may see:

perl-libs 5.26

in BaseOS while simultaneously trying to resolve:

perl-libs 5.32

from AppStream.

If the active module metadata does not permit the required package combination, DNF can report:

package ... is filtered out by modular filtering

This does not necessarily mean that the package is missing from the repository.

10. Safe Troubleshooting Workflow

For an AlmaLinux 8 cPanel server, a conservative troubleshooting sequence is:

Step 1 — Check installed packages

rpm -q perl perl-libs net-snmp

Step 2 — Check the Perl module

dnf module list perl

Step 3 — Refresh metadata

dnf makecache

Step 4 — Test dependency resolution

dnf update --assumeno

Step 5 — Check installed dependencies

dnf check

Only after these checks should you consider changing module streams or replacing packages.

11. What Not to Do

Avoid blindly executing commands such as:

dnf remove perl
dnf module enable perl:5.32
dnf update --allowerasing
dnf update --skip-broken

or:

dnf module reset perl

simply because DNF suggested them.

These options can be useful in specific situations, but they should not be the first response when the installed system Perl and its dependent packages are already consistent.

12. When dnf makecache Is Enough

Sometimes the apparent dependency conflict is caused by stale or inconsistent repository/module metadata.

In that situation:

dnf makecache

followed by:

dnf update --assumeno

can be enough.

For example, the affected server eventually reported:

Dependencies resolved.
Nothing to do.
Complete!

This confirmed that there was no longer a pending dependency transaction.

13. Recommended Verification Commands

After resolving the issue, run:

rpm -q perl perl-libs net-snmp

Then:

dnf module list perl

Then:

dnf check

Finally:

dnf update --assumeno

The combination gives you four useful pieces of information:

CheckPurpose
rpm -q perl perl-libs net-snmpConfirms installed versions
dnf module list perlShows active Perl streams
dnf checkChecks installed package dependencies
dnf update --assumenoTests whether DNF can resolve an update

14. Example of a Healthy Final State

A healthy system in this scenario can look like:

perl-5.26.3-423.el8_10.1.x86_64
perl-libs-5.26.3-423.el8_10.1.x86_64
net-snmp-5.8-33.el8_10.x86_64

with:

perl 5.26 [d][e]

and:

Dependencies resolved.
Nothing to do.
Complete!

That means there is no reason to force an update or replace the Perl packages.

15. Key Lesson

The most important lesson is to identify the root dependency instead of focusing on the last package mentioned in the error.

For example:

ea-php83-php-snmp
       ↓
    net-snmp
       ↓
 libperl.so.5.26
       ↓
 Perl 5.26

The PHP SNMP package is therefore not necessarily the problem.

Likewise, seeing Perl 5.32 packages in AppStream does not mean that the server should be migrated to Perl 5.32.

On an AlmaLinux 8 cPanel system where installed packages depend on Perl 5.26, the first objective should be to preserve the compatible Perl 5.26 environment and restore correct DNF metadata/module resolution.

Quick Recovery Checklist

Use this checklist before making any major package changes:

# 1. Check Perl and Net-SNMP
rpm -q perl perl-libs net-snmp

# 2. Check Perl module streams
dnf module list perl

# 3. Refresh repository metadata
dnf makecache

# 4. Test update resolution without changing anything
dnf update --assumeno

# 5. Check installed dependencies
dnf check

If the final commands report:

Dependencies resolved.
Nothing to do.
Complete!

then stop there. There is no need to force package removal or replacement.

Perl dependency errors on AlmaLinux 8 can look much more serious than they actually are, particularly on cPanel servers where EasyApache PHP packages depend on system components such as net-snmp.

The safest troubleshooting approach is:

identify the installed Perl ABI → check the active module stream → refresh DNF metadata → test dependency resolution → only then consider package changes.

Read more