Managing multiple runtime versions with Rocky Linux dnf module streams

Problem and thesis

System administrators often need different language runtimes—Python 3.9 for an older app, Python 3.11 for a new one—on the same host. Installing one version can break packages that depend on another, and reinstalling the OS is impractical. Rocky Linux’s dnf module streams solve this by letting you select a specific stream of a package, keeping binary compatibility with RHEL while simplifying updates.

How dnf module streams work

The dnf module system treats each runtime version as a separate stream. Each stream has its own repository metadata, so installing a module pulls only the RPMs for the chosen version. Because the streams are independent, dependency resolution stays clean; you won’t see “cannot install X because of conflicting Y” errors. The base system’s package lock ensures that only the declared stream versions are upgraded, which is crucial for production stability.

Enabling and verifying a stream

Run the command as root or with sudo:

sudo dnf module list 

Replace with the name of the module you care about, such as python or nodejs. The output lists available streams, for example:

python3:3.9/python3:3.11

To enable a stream, use:

sudo dnf module enable :

After enabling, install or refresh a package to see the new binary:

sudo dnf install 

Verify the installed version with:

rpm -q 

Check that the version matches the stream you enabled. The module configuration file lives in /etc/dnf/modules.d/; you can view it with cat /etc/dnf/modules.d/.conf.

Switching streams and operational impact

Changing a stream may require a reboot or service restarts if binaries are already loaded. Schedule a maintenance window before switching in production. The risk is that long‑running services continue to use the old binary until they are restarted, which can cause subtle bugs.

To minimize disruption, stop affected services, switch the stream, then start them again:

sudo systemctl stop 
sudo dnf module enable :
sudo systemctl start 

Trade‑offs and limitations

Not all third‑party packages provide dnf modules, so you may be limited to the runtime versions shipped with the base stream. Additionally, if the underlying RHEL streams shift, module availability can lag, meaning you might wait for a module update after a base release. Always review the module’s build requirements to ensure compatibility with your kernel and system libraries.

Worked example

Suppose you need Python 3.9 for a legacy web app and want to test Python 3.11 for a new microservice on a Rocky Linux 9 system.

1. List available python modules:

   sudo dnf module list python

   Result shows python3:3.9/python3:3.11.
2. Enable the 3.9 stream (if not already):

   sudo dnf module enable python3:3.9

3. Install the application’s required package:

   sudo dnf install python3-requests

4. Confirm the version:

   rpm -q python3-requests

   Expected output includes python3-requests-2.28.1-1.el9 and the underlying python3 binary should be 3.9.
5. Switch to 3.11 for the new service:

   sudo systemctl stop httpd   # example service
   sudo dnf module enable python3:3.11
   sudo systemctl start httpd

6. Verify the new binary:

   rpm -q python3-requests

   The package version stays the same, but the linked python3 binary now points to 3.11, which you can confirm with python3 --version.

Actionable closing

To adopt module streams safely:

• Run sudo dnf module list to see current streams.
• Enable the desired stream with sudo dnf module enable <module>:<stream>.
• Install or refresh the target package and check rpm -q <package>.
• Plan a reboot or service restart if the changed binaries are in use.
• Monitor module availability via dnf module list after each base OS update.

By using dnf module streams, Rocky Linux gives you the flexibility to run multiple runtimes side‑by‑side while keeping the system stable and update‑friendly.