EL 10: Module streams retired

AppStream module streams — introduced in EL 8 and debated ever since — retire in EL 10: the repositories no longer ship modular content, and while the dnf module command still exists, it only prints deprecation warnings. The era of picking software versions via module streams is over, replaced by versioned packages, third-party repositories, and containers.

What changed

Module streams were designed so AppStream could offer several major versions of one piece of software (PHP, PostgreSQL, Node.js, …) side by side, selected with dnf module enable php:8.1. In practice they brought repository-metadata bloat, image and Kickstart complexity, and module lifecycles shorter than the release itself.

EL 10’s answer is to stop distributing modular content:

• dnf module list / dnf module enable print deprecation warnings and show no usable modules;
• multi-version software moves to plain versioned package names (whatever the repository offers), or to EPEL / upstream repositories / container images.

EL 8 → EL 9 → EL 10

Item	EL 8	EL 9	EL 10
Modular content	introduced, widely used	still shipped, narrower scope	no longer distributed
dnf module	fully functional	functional	deprecation warnings only
Getting multiple versions	module streams	streams + versioned packages	versioned packages / third-party repos / containers

What it means for you

• Automation that depends on dnf module: Kickstart module --name=… lines and dnf module enable calls in Ansible or shell scripts all stop working (or warn) on EL 10 and must be cleaned up beforehand.
• Multi-version needs: for a non-default PostgreSQL / Redis / PHP, look to EPEL and third-party repos or containers; several projects (Redis among them) have already moved to versioned package names in third-party repos.
• Upgrading from EL 8/9: enabled streams do not “migrate” — after the upgrade you get whatever version the EL 10 repositories provide, so confirm each one.

Tip

Before upgrading, run dnf module list --enabled to enumerate every enabled stream and decide its EL 10 replacement. This is a mandatory item on any EL 9 → EL 10 migration checklist.

Checking and adapting

List currently enabled module streams (pre-upgrade audit)

dnf module list --enabled

Confirm the behavior on EL 10

dnf module list   # deprecation warning only, no module content

1. Export the enabled-module inventory before the upgrade;
2. Pick an EL 10 replacement for each stream (default-version package / versioned name / third-party repo / container);
3. Remove module directives from automation and image templates;
4. After the upgrade, verify service versions the new way.

Further reading

• EL 8: BaseOS and AppStream — the repository design where modularity was born
• DNF basics — DNF 4.20 and everyday commands
• EPEL & third-party repos — where multi-version software lives now
• Upgrading EL 9 → EL 10 — the full upgrade path