CentOS Stream vs RHEL rebuilds: library-version parity for compiled workloads on RHEL 9
0 reputation · 22 Apr 2024, 18:37 UTC
Constraint
A production fleet runs RHEL 9.4 and must remain on that minor release for the current support cycle. Development and CI systems need a no-cost environment that matches the production user-space ABI as closely as possible, especially glibc, libstdc++, and kernel headers, so that C++ binaries built in CI behave identically when deployed.
Trade-off
CentOS Stream 9 receives newer package versions ahead of the next RHEL minor release, which can introduce library versions not yet present in RHEL 9.4. RHEL-compatible rebuilds (Rocky Linux 9, AlmaLinux 9) track the exact RHEL 9.4 package set but lag on security errata until the upstream rebuild publishes them. Stream offers faster errata; rebuilds offer stricter version parity.
Open questions
- For a workload that cannot tolerate any glibc or libstdc++ version drift, does the rebuild’s delayed errata window pose a greater operational risk than Stream’s continuous version advance?
- Can a pinned Stream repository snapshot (e.g., a specific compose date) provide a stable-enough ABI baseline while still receiving selective security backports?
- Are there documented cases where a binary compiled against Stream’s newer toolchain fails on RHEL 9.4 due to symbol-version differences?
centos