Choosing AppStream Module Streams on Rocky Linux 9: A Decision Guide for Node.js, Python, PostgreSQL, and nginx

Problem: Which AppStream stream should I enable on Rocky Linux 9?

Rocky Linux 9 ships with several AppStream modules that expose multiple streams for the same language or database. A single stream can be active per module, and each stream has its own end‑of‑life (EOL) and support cadence. Choosing the wrong stream can lead to security gaps, broken dependencies, or a forced upgrade path that conflicts with other packages.

Decision & Constraints

Decision: Pick one stream per module that matches your application’s feature needs while staying within the supported lifecycle. Constraints:

• Only one stream may be enabled at a time per module.
• Enabling a new stream requires dnf module reset followed by enable and a dnf distro-sync to resolve dependencies.
• Module streams have specific EOL dates; you must avoid selecting a stream that is already expired or will expire soon.
• Third‑party repos (EPEL, RPM Fusion) may ship packages built against the default stream; switching streams can cause missing dependencies.
• FIPS mode and container images may impose additional constraints.

Supported Streams – Compact Comparison

Module	Default Stream	Alternate Stream	EOL	Typical Use Case
nodejs	18 LTS	20 LTS	2025‑04 / 2026‑04	Modern JavaScript apps, long‑term support
python3	3.11	3.12	2027‑10 / 2028‑10	New language features, future‑proofing
postgresql	15	16	2027‑11 / 2028‑11	Performance improvements, newer extensions
nginx	1.24	1.26	2025‑06 / 2026‑06	HTTP/3, TLS 1.3 enhancements

Trade‑Offs

• Default streams are the most stable: they receive security patches quickly, have proven compatibility with the core OS, and are the target of the Rocky Linux support team.
• Alternate streams provide newer language features or database extensions, but they come with a shorter support window and may introduce library changes (e.g., libpq.so.5 vs. libpq.so.6) that can break other packages.
• Switching streams forces dnf distro-sync to upgrade or downgrade many packages, potentially restarting services. In a production environment, schedule a maintenance window.
• Mixing streams across modules is allowed, but dnf will block incompatible combinations (e.g., enabling nodejs:20 while python3:3.11 has a dependency on a library built against the default stream).
• Third‑party repos may not yet offer the alternate stream; enabling it can lead to “no matching package” errors.

Concrete Implementation – Enabling Node.js 20 LTS

Below is a step‑by‑step example on a fresh Rocky Linux 9 host. All commands must be run as root or with sudo and assume the base OS is fully updated.

1. Check current module status

   # dnf module list nodejs
   # dnf module list --enabled nodejs
   

   Look for the stream marked [d] (default) and any enabled streams.

2. Reset the module to clear any previous stream

   # dnf module reset nodejs -y
   

3. Enable the desired stream

   # dnf module enable nodejs:20 -y
   

   Verify the change:

   # dnf module list nodejs | grep -E '20|enabled'
   

4. Synchronize the distro to apply the new stream

   # dnf distro-sync -y
   

   During this step, dnf may upgrade or downgrade many packages and restart services. Monitor the output for any “service restarted” messages.

5. Install the application stack

   # dnf install nodejs npm -y
   

6. Validate the installation

   # node --version
   v20.x.x
   # npm --version
   

   Check the underlying libraries to ensure the expected sonames are used. For example, if you later install a PostgreSQL client that depends on libpq, run:

   # ldd $(which psql) | grep libpq
   libpq.so.6 => /usr/lib64/libpq.so.6
   

Validation Checklist for Any Module Switch

• Enabled streams: dnf module list --enabled should list only the intended stream.
• Repository state: dnf repolist enabled must include AppStream and any third‑party repos that provide the stream.
• Package compatibility: For each installed package that depends on shared libraries, run ldd to confirm the expected sonames. Example: ldd $(which psql) | grep libpq.
• EOL check: dnf module info <module>:<stream> displays the upstream EOL. Ensure the chosen stream’s EOL is beyond your planned maintenance window.
• Service health: After dnf distro-sync, use systemctl status <service> for critical services to confirm they are running.

Limitations & Practical Tips

• Because Rocky Linux 9 is built on Red Hat Enterprise Linux 9, the module streams mirror RHEL’s streams and their support dates. Always cross‑check with the RHEL 9 release notes for the exact EOL.
• When using EPEL or RPM Fusion, verify that the alternate stream is available. If not, you may need to install from source or use a container image that already contains the desired stream.
• For FIPS‑validated deployments, some alternate streams may not provide a FIPS‑validated provider. Test openssl version -a and openssl ciphers -v | grep FIPS after enabling a stream that changes the crypto stack.
• Container images ignore host module streams. If you use containers, pin the base image tag (e.g., rockylinux/rockylinux:9-202405) to match the expected stream.
• Plan migrations before Rocky Linux 10 releases, as default streams will reset and the module architecture may change.

Conclusion

By selecting a single, supported stream per module, respecting EOL dates, and following the enable–sync–validate workflow, you can keep your Rocky Linux 9 systems secure, stable, and aligned with your application requirements. Use the table and checklist above to make an informed decision and to verify the outcome before deploying to production.