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.
FAQ
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.
Hi @rexbinary. Probably the title could be better, yeah. This post is on the Fedora Community blog, which says at the top “News and updates for about the Fedora Project community that develops supports and promotes Fedora”. I’ll add that to the description on Fedora Discussion, too.
I do think that this is big enough news that it’s worth sharing beyond just the epel-devel mailing list — and that kind of thing is exactly what the Community Blog is for. But perhaps it shuld have been “Announcing the beginning of EPEL 9”, or similar.
EPEL is the repository, not a specific list of packages. End users can enable the repository now and install any available package. Trying to delay an announcement until a specific set of packages are available is an exercise in futility because no one would agree on what those specific packages should be. The list would just grow continuously until an arbitrary cutoff was made.
If you have specific packages that you care about, we have a guide for requesting them that was linked in the announcement. Or even better, become a package maintainer and add the packages yourself.
Moving to the next major version without verifying what you need is available will always be problematic. The same was true with previous EPEL launches.
That’s incorrect. EPEL has never done mass rebuilds to populate new versions of the repository. This is covered in the FAQ. We were considering launching EPEL9 Next by itself and later doing a mass rebuild to populate EPEL9, but we ended up going a different route.
EPEL 9 Next didn’t launch first, we launched them at the same time, with this announcement. EPEL Next is not a standalone repository. It is an additional repository that is only sometimes necessary. The vast majority of packages from the main EPEL repository.
I am the person who told Carl that there had not been any mass rebuilds.
I don’t remember any mass rebuilds for EPEL when RHEL came out for EL6 or EL7 and there definitely were no mass rebuilds for EL8. I do see there was one in 2015 to update a large number of packages to a new macro set, but I don’t remember any others.
Matt Domsch also used to do personal mass rebuilds to see if packages were still buildable from RHEL5 and RHEL6 updates but those were on his own systems and I don’t think they were redone in koji. [The build system when EL5 was in the plague system before 2011 I am not too familiar with.]
A half dozen people reviewed the draft announcement and thought it was great. The feedback on the announcement has been overwhelmingly positive. The great thing about open source is that if you don’t like something you can get involved to make it better. I encourage you to do so, we could always use more help in EPEL.
To be clear, I think it’s likely that any communication can be improved, and that’s often most obvious in hindsight. Communication is hard.
FWIW I am working on a tool to simplify mass-branching the packages we need in EPEL9, so hopefully this will simplify the process compared to previous EPEL branches.
Yes, I first proposed this several months ago but life got in the way. Happily I can now focus on this as part of $dayjob!