On behalf of the EPEL Steering Committee, I’m pleased to announce the availability of EPEL 9. This is the culmination of five months of work between the EPEL Steering Committee, the Fedora Infrastructure and Release Engineering team, and other contributors. Package maintainers can now request dist-git branches, trigger Koji builds, and submit Bodhi updates for EPEL 9 packages.
Instructions to enable the EPEL repository are available in our documentation. If there is a Fedora package you would like to see added to EPEL 9, please let the relevant package maintainer know with a package request.
How can EPEL 9 launch before RHEL 9?
Thanks to CentOS Stream 9, we have a close approximation of what RHEL 9 will look like when it is released. We have set up EPEL 9 to build against CentOS Stream 9. After the RHEL 9 release, we will switch it to build against RHEL 9 instead. We intend for this switch to be basically invisible to package maintainers and users.
What about EPEL Next?
EPEL 8 Next is still available for package maintainers when they need to build against CentOS Stream 8 instead of RHEL 8. EPEL 9 Next is also now available to complement EPEL 9,
but it won’t be necessary until after EPEL 9 switches to build against RHEL 9.
Why isn’t fedpkg available in EPEL 9 yet?
We believe that most package maintainers do their EPEL work from Fedora systems. Because of this we chose not to delay this announcement to wait for fedpkg (and all its dependencies) to be added to EPEL 9. fedpkg-1.41-2 (which adds support for requesting epel9 and epel9-next branches) is already available in the Fedora, EPEL8, and EPEL7 repositories. If you would like to see fedpkg in EPEL 9 as well, please submit a package request.
What happened to the mass rebuild plan?
We have previously communicated a plan to launch EPEL 9 Next first and then wait until the RHEL 9 release to launch EPEL 9. This would have included performing a mass branch and mass rebuild from EPEL 9 Next to EPEL 9. This plan made sense to us from the implementation perspective. However, we eventually realized that it would result in unnecessarily complicated instructions for package maintainers and users. It also had the drawback of not being ready on the RHEL 9 release day, even though it would follow soon afterwards.
We revised our plan to simplify our messaging and to launch EPEL 9 before RHEL 9. This removes the need for a mass rebuild and gives package maintainers multiple months to build their packages for the RHEL 9 release.