From Fedora Project Wiki

mNo edit summary
 
(11 intermediate revisions by one other user not shown)
Line 1: Line 1:
'''THE EPEL WIKI PAGES ARE NO LONGER USED AND ARE OUT OF DATE - SEE [https://docs.fedoraproject.org/en-US/epel/ THE EPEL DOCS] FOR UP TO DATE INFORMATION.'''
(These wiki pages are being kept for historical reference only.)
= EPEL Next =
= EPEL Next =
== Introduction ==


EPEL packages are built against RHEL.  EPEL Next is an additional repository
EPEL packages are built against RHEL.  EPEL Next is an additional repository
Line 22: Line 28:
merge commits from other branches and submit a build just like you would for
merge commits from other branches and submit a build just like you would for
other EPEL or Fedora branches.
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` and 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 ==
== FAQ ==
Line 42: Line 63:
packages compatible with the next minor release of RHEL.  Additionally, EPEL Next isn't exclusively useful for CentOS Stream.  It's also useful for:
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 Beta releases.
- RHEL itself temporarily at minor release time when an EPEL package needs to be rebuilt but hasn't been yet.
* 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|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 [[EPEL/GuidelinesAndPolicies|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 [[EPEL_incompatible_upgrades_policy|incompatible upgrades process]].  If you want to be able to change the version whenever you feel like it, take a look at [[EPEL/Playground|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 <package_name>` should pick the correct available package from the appropriate repository.  If that doesn't work, please file a [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL bug] to let the maintainer know.
 
=== How do I report a package that needs to be rebuilt in EPEL Next? ===
 
File a [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL 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.


[[Category:EPEL]]
[[Category:EPEL]]

Latest revision as of 20:04, 6 January 2022

THE EPEL WIKI PAGES ARE NO LONGER USED AND ARE OUT OF DATE - SEE THE EPEL DOCS FOR UP TO DATE INFORMATION.

(These wiki pages are being kept for historical reference only.)

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 .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 and 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

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 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 <package_name> 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.