Rocky 10: module streams are gone, here is what breaks

Test scope

Two environments:

Environment	Purpose
almalinux:9 container (EL9 AppStream)	shows what module streams used to look like
Rocky Linux 10.2 VM + almalinux:10 container (dnf 4.20.0)	shows actual EL10 behaviour

Log: plans/content-expansion/evidence/logs/module-streams-el9-el10.log. Screenshot: public/evidence/module-streams/rocky-no-modules.png.

What a stream was on EL9

On EL9 one package exposed several version tracks:

$ dnf module list
Name    Stream  Profiles                        Summary
nodejs  18      common [d], development, ...    Javascript runtime
nodejs  20      common [d], development, ...    Javascript runtime
nodejs  22      common [d], development, ...    Javascript runtime
nginx   1.22    common [d]                      nginx webserver
php     8.1     common [d], devel, minimal      PHP scripting language

The resulting RPM carries a module build tag:

# dnf -y module install nodejs:22/common
$ rpm -q nodejs
nodejs-22.23.2-2.module_el9.8.0+322+f4aa738c.x86_64

.module_el9.8.0+322+f4aa738c never appears on EL10.

On EL10 the command only warns

$ dnf module list
WARNING: modularity is deprecated, and functionality will be removed in a future release of DNF5.
(no list follows)

$ dnf module list nodejs
WARNING: modularity is deprecated, and functionality will be removed in a future release of DNF5.
Error: No matching Modules to list

$ dnf module enable nodejs:20
Error: Problems in request:
missing groups or modules: nodejs:20

/var/lib/dnf/ holds only history.sqlite, repos and friends — no module metadata at all.

The replacement: versioned package names

EL10 expresses “multiple versions” with ordinary package names:

$ dnf -q list --available 'php8*'
php8.4.x86_64       8.4.24-1.el10_2   appstream
php8.4-cli.x86_64   8.4.24-1.el10_2   appstream

So php defaults to 8.3 and php8.4 can be installed alongside; nodejs is 22.x with no 18/20/24 tracks; exact versions are pinned by NEVRA, e.g. dnf install nodejs-22.23.1-4.el10_2.

Migration checklist

EL9 usage	EL10 replacement
dnf module enable nodejs:20	drop it; dnf install nodejs (22.x)
dnf module install php:8.2/common	dnf install php8.4 (or the matching versioned name)
dnf module list --enabled	none; use dnf list --installed
code that greps .module_el9 in rpm -q	switch to version checks
Ansible dnf: name=@nodejs:20/common	name=nodejs

Common traps

• Retrying does not help: dnf module enable is a hard error on EL10 and will keep failing in CI;
• Assuming packages disappeared: dnf list --available nodejs still lists them, just without alternative tracks;
• Major upgrades: rpm -q output changes because module-tagged builds have no equivalent on EL10;
• Multiple major versions: expressed by different package names (php8.4), not by streams.

Practice: rewrite one module command

dnf module list nodejs 2>&1 | tail -2
dnf -q list --available nodejs php8.4 2>/dev/null | head -4

Checks:

1. The first command reports No matching Modules to list on EL10;
2. The second lists concrete versions for nodejs and php8.4;
3. Every module enable/install in your scripts is replaced by a package name;
4. rpm -q confirms installed packages carry no .module_el* tag.

FAQ

常见问题

Will modularity come back?

No. The warning states modularity is deprecated and DNF5 removes the commands; the new model is plain packages.

Is EL9 modularity still usable?

Yes for the EL9 lifetime, but any upgrade path to EL10 requires rewriting those commands first.

What if I need an older major version?

Use containers for the old runtime, or a third-party repository; official EL10 repos only ship the current major version.

Next steps

• Repository conflicts: /en/repo-priority/
• Offline installs: /en/offline-updates/
• Transaction rollback: /en/dnf-history-rollback/