On behalf of the EPEL Steering Committee, I’m happy to announce the availability of EPEL 10. EPEL 10 already contains over 10,000 packages, built from over 3,600 source packages. This is a result of the hard work of over 150 Fedora package maintainers.
What is EPEL?
Extra Packages for Enterprise Linux (EPEL) is an initiative within the Fedora Project to provide high quality additional packages for CentOS Stream and Red Hat Enterprise Linux (RHEL). The goal for EPEL packages is to enhance these distributions, without disturbing or replacing packages from the default repositories.
What’s new?
For the EPEL 9 release, we started building packages about six months before the RHEL 9 release by using CentOS Stream 9 as the initial build environment. For EPEL 10, we’re expanding on that approach and doing the same thing for each minor version of RHEL 10. We will have separate DNF repositories for each minor version of RHEL 10, including CentOS Stream 10 as the leading minor version. Packages built for one minor version will carry forward to the next minor version. You can find more details about this structure in our branching documentation.
Requesting packages
While many packages are already available in EPEL 10, it’s possible that your favorite package isn’t one of them yet. We don’t automatically branch packages from the previous major version to the next major version. Individual package maintainers opt-in to building for each new major version. You can request additional packages by following our package request guide.
Getting started
Ready to start using EPEL 10? Check out our getting started guide for instructions to set up the repository on your system.
Can you create BZs for every package that has epel9 branch? I maintain bunch of epel9 packages, but going through them one by one will be a pain. If I had a BZ issue asking me to build it for EPEL10, my life would be easier.
I don’t think there is (or should be) an automatic assumption that all packages that are in EPEL9 will be in EPEL10.
Speaking for myself, the sets of packages that I maintain in epel9 and epel10 overlap, but aren’t subsets of each other (i.e. there are packages in epel9 that won’t be in epel10 unless requested, and there’s already packages in epel10 that I won’t add in epel9).
So filing bugzillas for my packages that are in epel9 but not in epel10 would just add a lot of noise, and I would likely just close them all with “I don’t plan to add this unless specifically requested by an actual user”.