EPEL Next
- Introduction
- Example Workflow
- FAQ
- How do I enable EPEL Next?
- If I build my package in EPEL do I also need to build my package in EPEL Next?
- Are all EPEL packages also in EPEL Next?
- Why isn’t this called EPEL Stream?
- When I request an epel8 branch, will an epel8-next branch be requested automatically?
- Can I use EPEL Next to provide a newer version of a package than what’s in EPEL?
- Why is the package I’m looking for in EPEL but not in EPEL Next?
- How do I report a package that needs to be rebuilt in EPEL Next?
- Why does epel-next-release require epel-release?
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 .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-nextand wait for the branch to be created -
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
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 epel8 branch, will an epel8-next branch be requested automatically?
No. That is something that used to happen for EPEL Playground. Most maintainers didn’t like it. Both EPEL Next and EPEL Playground are now 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. If you want to be able to change the version whenever you feel like it, take a look at EPEL Playground.
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 = 8-11.el8 needed by epel-next-release-8-11.el8.noarch
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.