EPEL Next
Introduction
EPEL packages are built against RHEL. EPEL Next is an additional repository that allows package maintainers to alternatively build against CentOS Stream. This is sometimes necessary when CentOS Stream contains an upcoming RHEL library rebase, or if an EPEL package has a minimum version build requirement that is already in CentOS Stream but not yet in RHEL. EPEL Next has its own distgit branches, koji build targets, and bodhi releases.
EPEL Next packages have .next
appended to the disttag (e.g. a disttag
of .el9.next
for epel9-next) to provide an upgrade path from an EPEL
package that was built from the same distgit commit. A package
maintainer can rebuild the same commit for both EPEL and EPEL Next and
get two different NVRs in koji. Within six months, the build requirement
necessitating building in EPEL Next should be in RHEL, and at that time
the package maintainer can do a normal release bump commit in the EPEL
branch and get a newer NVR than both the previous EPEL and EPEL Next
packages.
To get started with EPEL Next, request the corresponding branch for the EPEL release you are targeting, e.g. request an epel9-next branch to rebuild an EPEL 9 package against CentOS Stream 9. Once the branch is created you can merge commits from other branches and submit a build just like you would for other EPEL or Fedora branches.
Example Workflow
The workflow for building and releasing a package in EPEL Next is intentionally very similar to EPEL itself.
In this example, the scenario is that you have an EPEL package (built against RHEL) that installs on RHEL, but not on CentOS Stream, due to a dependency that was rebased in the distro which is destined for the next minor release of RHEL. You can use EPEL Next to build a compatible package now.
-
fedpkg request-branch epel9-next
and wait for the branch to be created -
git checkout epel9-next
-
git merge epel9
-
git push
-
fedpkg build
-
submit bodhi update via web interface or cli
This will result in an EPEL Next package that is the same as the
existing EPEL package, except for the .next
suffix on the disttag and
being built against CentOS Stream 9. Your epel9-next branches can
diverge from the corresponding epel9 branches as needed. If an update
for your EPEL package requires a minimum version of a dependency that is
only in CentOS Stream so far, you can update in the epel9-next branch
first, then merge from epel9-next to epel9 when the dependency is added
to the next RHEL minor release.
FAQ
If I build my package in EPEL do I also need to build my package in EPEL Next?
Probably not. Due to the strong compatibility guarantees of RHEL, most EPEL packages built against RHEL install just fine on CentOS Stream. But there are some situations where it is necessary to rebuild an EPEL package to get it to install on CentOS Stream, and EPEL Next exists to provide package maintainers a place to do just that.
Are all EPEL packages also in EPEL Next?
No. EPEL Next is designed to be a small overlay on top of EPEL. The epel-next-release package requires epel-release.
Why isn’t this called EPEL Stream?
The term stream is already massively overloaded. "Next" correctly describes the purpose of the repository, which is providing packages compatible with the next minor release of RHEL. Additionally, EPEL Next isn’t exclusively useful for CentOS Stream. It’s also useful for:
-
RHEL Beta releases.
-
RHEL itself temporarily at minor release time when an EPEL package was already rebuilt for a library change in EPEL Next but hasn’t been rebuilt in EPEL yet.
When I request an epel9 branch, will an epel9-next branch be requested automatically?
No. That is something that used to happen for EPEL Playground. Most maintainers didn’t like it. EPEL Next is opt-in.
Can I use EPEL Next to provide a newer version of a package than what’s in EPEL?
EPEL Next is bound by the same guidelines and policies as regular EPEL. If a version upgrade is inappropriate for EPEL, it’s inappropriate for EPEL Next. If a version upgrade is unavoidable because of upcoming changes in RHEL, then you must follow the incompatible upgrades process.
Why is the package I’m looking for in EPEL but not in EPEL Next?
EPEL Next is not a complete rebuild of all EPEL packages. Most EPEL packages already install on CentOS Stream correctly. EPEL Next is an additional repository to be used with regular EPEL (not instead of) to resolve the occasional compatibility issue. If you install both epel-release and epel-next-release, `dnf install ` should pick the correct available package from the appropriate repository. If that doesn’t work, please file a bug to let the maintainer know.
How do I report a package that needs to be rebuilt in EPEL Next?
File a bug to let the maintainer know.
Why does epel-next-release require epel-release?
If you try to install only epel-next-release without epel-release available, you’ll see an error like this.
Error: Problem: conflicting requests - nothing provides epel-release = 9-7.el9 needed by epel-next-release-9-7.el9.noarch from @commandline
This is because epel-next-release intentionally requires epel-release. EPEL Next is designed to be used with EPEL, not as a replacement. EPEL Next packages will often require other packages in EPEL.
Want to help? Learn how to contribute to Fedora Docs ›