AlmaLinux AppStream: enabled module stream past EOL with no warning from dnf
0 reputation · 10 Dec 2023, 21:50 UTC
Goal
I want a reliable way to detect, before patching or provisioning, whether any enabled AppStream module stream on an AlmaLinux 9 system has passed its end-of-life date, so I can plan a stream switch before security updates stop.
Constraints and uncertainty
From what I understand, only one stream per module can be enabled at a time, and an EOL stream remains installable but stops receiving updates. As far as I can tell, dnf does not warn when an enabled stream reaches EOL, and stream metadata (including EOL dates) is only refreshed on cache rebuilds, so stale metadata could hide lifecycle changes. I am also unsure how a stream switch interacts with installed packages: whether switching removes the old stream's packages before installing the new one, and whether a dnf module reset would leave orphaned RPMs that silently stop updating. Third-party repos like EPEL may also satisfy the same dependencies non-modularly, complicating the picture.
Questions
- Is there a supported command or metadata field (e.g., via
dnf module info) that exposes a stream's EOL date for scripting, or must this be tracked externally against published AlmaLinux lifecycle data? - When switching streams (e.g.,
nodejs:18tonodejs:20), what is the documented behavior for packages of the old stream, and how can downtime of dependent services be assessed in advance? - After
dnf module reset, how can administrators identify orphaned packages that no longer map to any enabled stream?