EPEL Packaging

This page contains guidelines which are not relevant or are no longer relevant to Fedora, but still apply to EPEL packages. These guidelines are designed to avoid conflict with the larger Fedora Packaging Guidelines, but should any conflicts occur, these guidelines should take precedence on EPEL packages.

As a reminder, these guidelines only apply to EPEL packages, not to Fedora packages.

Package Dependencies

All EPEL package dependencies (build-time or runtime) MUST ALWAYS be satisfiable within the Target Base (as defined by EPEL Policy) or EPEL itself. Weak package dependencies are allowed on packages from other RHEL channels that are not part of the Target Base, such as the HighAvailability or ResilientStorage channels. This allows for repoclosure with only the Target Base, but allows EPEL packages to pull in other packages via weak dependencies when additional channels are enabled.

This does not mean that EPEL packages should incorrectly identify a dependency as weak (e.g. changing a Requires to a Recommends). On a case by case basis, exceptions to this policy may be granted by the EPEL Steering Committee. To request an exception open an issue and add the "meeting" tag.

ELN

ELN is a new buildroot and compose process for Fedora that takes Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux compose. The packages included are thus based on what is planned to be included in the next major RHEL release, and in that way it is already useful for EPEL packagers.

ELN Extras, however, is an extension that is mostly driven by EPEL packagers. Given that one of the pain points in bootstrapping a new EPEL is in processing the dependency graph of the packages our packagers are actually interested in (whether they are a library that some in-house or ISV software needs, or a tool) and getting them branched and built, we can use ELN Extras in this way:

  • add packages to ELN Extras' content resolver input, e.g. KDE packages; note that this has sufficient metadata to indicate who will maintain such packages

  • check the dependencies pulled in

The former list is what packagers actually care about, the latter is just what needs to be brought in.

EPEL 8

Scriptlets

Fedora has been moving towards the use of file triggers and away from requiring that packagers cut and paste scriptlets into loads of packages. At the time of this writing, we are trying to backport all of these to EPEL8, so that fedora packages are easily able to build on EPEL8 without any changes. When EPEL 8 becomes old enough, that these backports are not feasible and/or wanted, we will list them here.

RPM Macros

Not all macros defined in (or built into) existing Fedora packages will work when a spec is converted for use in EPEL. epel-rpm-macros backports the newer macros and is installed by default in EPEL mock chroots.

Scriptlets

Fedora has been moving towards the use of file triggers and away from requiring that packagers cut and paste scriptlets into loads of packages. These scriptlets would still be needed for EPEL, and as scriptlets are no longer needed in any Fedora release, they’re moved here.

Python

The Fedora Python Packaging Guidelines underwent a major overhaul in 2021. The macros used in these guidelines are also available in RHEL 9. EPEL 9 Python packages SHOULD use these guidelines. EPEL 9 Python packages MAY use the older 201x-era Fedora Python Packaging Guidelines. EPEL 8 Python packages MUST use the older guidelines. Python 2 packages should also refer to the Python 2 section of the Fedora Python Packaging Appendix. New Python 2 packages SHOULD NOT be added to EPEL 8, because the RHEL 8 Python 2.7 Application Stream will be retired in June 2024.

Automatically generated dependencies

The Python run-time dependency generator mentioned in the Fedora Python Packaging Guidelines is enabled by default for EPEL 8 and EPEL 9 builds.

The dependency generator in RHEL 8 is significantly limited compared to the one in Fedora and RHEL 9. Simple dependencies and minimum/maximum versions work correctly, but more advanced specifications such as environment markers and compatible release clauses do not. This can lead to missing dependencies, included dependencies that should have been skipped, or other incorrect behavior. The packager MUST inspect the generated requires for correctness. If the software uses an advanced dependency specification that does not parse correctly, the packager MUST ensure the dependency is included. This can be done either by patching the source to achieve the desired result from the generator, or by using an explicit Requires: statements.

Want to help? Learn how to contribute to Fedora Docs ›