AlmaLinux 9 AppStream Module Stream EOL Transitions Disrupt Container Build Reproducibility

Context

AlmaLinux 9 manages languages, databases, and tools through modular streams in the AppStream repository, each with a published end-of-life date. When a stream expires, dnf automatically switches to the default stream for that module, which can also change between minor releases such as 9.2 and 9.3.

Problem

In a pinned development environment—container Dockerfiles, Vagrant boxes, or kickstart installations—an implicit module stream selection causes unexpected version upgrades the moment the base image is rebuilt after a stream EOL. The official documentation recommends pinning streams with module enable <module>:<stream>, yet the exact syntax and its persistence across image layers are not consistently demonstrated in AlmaLinux examples.

Open Decision

It remains unclear whether AlmaLinux will publish long-term supported streams for critical modules (Python 3.9, Node.js 18, PostgreSQL 13) aligned with the distribution’s 10-year lifecycle, or rely on upstream EPEL modular streams that have shorter support windows. Third-party modular repositories add further lifecycle mismatch risk.

Will AlmaLinux guarantee LTS-equivalent streams for core development modules? How should stream pinning be expressed in a multi-layer container build to survive automatic stream switching? What is the recommended pattern for cross-repository module consistency when EPEL Modular streams diverge in EOL timing?