Application Streams and DNF modules on RHEL: what RHEL 10 changes

What it is

On RHEL 8 and 9, part of the AppStream repository ships as DNF modules: named streams (for example postgresql:15) that let more than one upstream version of a component be published for one OS major release, with only one stream active per module at a time. dnf's own modularity documentation defines a module stream this way, and describes package filtering that hides packages from any stream that isn't the active one.

Why it matters

Modules let RHEL 8/9 offer several major versions of the same component without changing the OS release, at the cost of dnf having to track which stream is active. RHEL 10 drops modularity. Oracle Linux 10, a rebuild of the same sources, documents it plainly: DNF modularity is not available, that Application Stream packages there install directly with dnf install, and its release notes list the module Kickstart command as deprecated because Anaconda's own modularity support is deprecated.

How to apply

• On RHEL 8/9, the working sequence is list, enable, install: dnf module list, dnf module enable <name>:<stream>, then dnf install <package>; dnf module reset <name> clears the active stream selection to switch to a different one.
• Before scripting a dnf module enable step for a RHEL 10 target, check whether the package is modular there at all — treat modularity as an RHEL 8/9-era mechanism rather than something that automatically carries forward.
• When writing a Kickstart file meant to run on RHEL 10 or its rebuilds, install the package directly in %packages instead of using the module command.

Pitfalls

• Assuming dnf module list output and behaviour is identical across RHEL 8, 9 and 10; a package that needed module enablement on RHEL 8/9 may simply be a normal package on RHEL 10.
• Leaving a module stream enabled without installing anything from it — dnf still uses the enablement to filter which versions are visible to later installs.