AlmaLinux 9 module stream switching versus rootless Podman for reproducible development environments

Context

AlmaLinux 9 ships dnf module streams for language runtimes such as Node.js, Python, and Go, allowing version selection via dnf module install nodejs:18. Switching streams requires dnf module reset followed by dnf module enable, a non‑transactional sequence that can leave orphaned packages or unresolved dependencies. The AlmaLinux Build System publishes these streams, yet a consolidated lifecycle and support matrix for each stream is not documented in a single authoritative source.

Alternative

Podman provides rootless containers as a distribution‑agnostic isolation layer. A container based on almalinux:9 can pin exact runtime versions without mutating the host package database. However, rootless operation introduces filesystem‑permission and networking constraints that may affect tooling such as bind‑mounted source directories or local database servers.

Open decision

Neither the official AlmaLinux documentation nor the SIG guidelines explicitly recommend one approach over the other for repeatable development environments. Teams must weigh module‑stream mutability against container‑runtime overhead and SELinux interactions.

What criteria should guide the choice between dnf module streams and rootless Podman containers when the goal is a reproducible, low‑friction development environment on AlmaLinux 9? How can the undocumented stream support windows be factored into that decision? What SELinux policy adjustments are typically required for each path?