EPEL Next

EPEL Next

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 .el8.next for epel8-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 epel8-next branch to rebuild an epel8 package against CentOS Stream 8. 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 epel8-next
• git checkout epel8-next
• git merge epel8
• 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 8. Your epelX-next branches can diverge from the corresponding epelX 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 epelX-next branch first, then merge from epelX-next to epelX when the dependency is added to the next RHEL minor release.

FAQ

How do I enable EPEL Next?

   dnf install epel-next-release

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 needs to be rebuilt but hasn't been yet.