A large part of my day job is working on CentOS Stream. Naturally I would
like it to be successful and have wide adoption. I know that EPEL will play
a big role in this success. EPEL is extremely popular. Many users consider
RHEL and CentOS unusable without it.
The problem we are facing is that EPEL 8 cannot be 100% compatible with
RHEL/CentOS 8 and CentOS 8 Stream at the same time. It is not uncommon for
RHEL to ship library soname changes in minor releases. In the RHEL 8 cycle,
those changes are showing up in CentOS 8 Stream first. EPEL 8 builds
against the latest RHEL 8 release. This can result in EPEL 8 packages that
are uninstallable on CentOS 8 Stream due to the library differences. One
prominent example we have already seen is llvm-libs, which has increased its
library soname in every RHEL 8 minor release so far. Another increase is
planned for RHEL 8.3, which has already been released in CentOS 8 Stream.
There are likely other incompatibilities that haven't been noticed yet. I
expect this problem to grow worse as RHEL development continues and more
packages are added to EPEL 8. This situation is hurting the adoption of
To solve this problem, I am proposing that we create a new repository called
EPEL 8 Next.
- built against CentOS 8 Stream
- opt-in for packagers (must request epel8-next dist-git branch)
- opt-in for users (part of epel-release but disabled by default)
- used *with* epel8, not *instead of*
This will provide EPEL packagers a place where they can update their
packages when necessary to be compatible with CentOS 8 Stream. These
packages would also be useful for RHEL 8 users during the gap between a RHEL
minor release and the equivalent CentOS 8 Linux rebuild. In theory this
repository should also be directly consumable by RHEL 8 Beta releases.
Similar to RHEL itself, breaking changes could be permitted in epel8-next in
preparation for delivering them to epel8 around the time of the next RHEL
This proposal may sound similar to epel8-playground. However, that was
still built against RHEL 8, so it didn't solve the compatibility issue with
CentOS 8 Stream. This proposal does draw on lessons learned from the
- no automatic builds via packages.cfg
- opt-in rather than opt-out
- layering on top of epel8, rather than duplicating content
I first suggested this idea at the last EPEL Steering Committee meeting, and
we plan to discuss it again during the next one. Please share your thoughts
on this proposal.