Packaging Guidelines and Policies for EPEL
The packages in EPEL follow the Fedora Packaging and Maintenance Guidelines — that includes, but is not limited to the packaging guidelines, the package naming guidelines, and the package review guidelines that are designed and maintained by the FESCo, and Packaging Committee. EPEL-specific exceptions are documented here and in the EPEL Packaging page.
Please note that the sections "Guidelines" and "Policies" use their names on purpose. Consider the guidelines as something that should be followed normally, but doesn’t have to if there are good reasons not to — please ask EPEL members in case you are in doubt if your reasons are good. The word policies has a stronger meaning, and what is written in that section should be considered rules that must always be followed.
Package maintenance and update policy
EPEL wants to provide a common "look and feel" to the users of our repository. Thus the EPEL Steering Committee wrote this policy that describes the regulations for package maintenance and updates in EPEL, that are a bit more strictly regulated then they are in Fedora now.
Digest
The goal is to have packages in EPEL that enhances the Enterprise Linux distributions the packages were build against without disturbing or replacing packages from that distribution. The packages in the repository should, if possible, be maintained in similar ways to the Enterprise Packages they were built against. In other words: have a mostly stable set of packages that normally do not change at all and only changes if there are good reasons for it — so no "hey, there is a new version, it builds, let’s ship it" mentality.
Policy
EPEL packages should only enhance and never disturb the Enterprise Linux distributions they were built for. Thus packages from EPEL should never replace packages from the target base distribution. Kernel modules are not allowed, as they can disturb the base kernel easily.
In EPEL8 or later, it is permitted to provide an alternative non-modular package to any package found only in a non-default RHEL module.
The Target Base for each distribution has been defined in older mailing list discussions as the version of Red Hat Enterprise Linux that the Koji builders have access to.
-
EPEL 10’s leading minor version is built against CentOS Stream 10 repos
-
baseos
-
appstream
-
crb
-
-
EPEL 10’s trailing minor versions are built against Red Hat Enterprise Linux 10 channels
-
rhel-10-for-*-baseos-rpms
-
rhel-10-for-*-appstream-rpms
-
codeready-builder-for-rhel-10-*-rpms
-
-
EPEL 9 Next is built against CentOS Stream 9 repos
-
baseos
-
appstream
-
crb
-
-
EPEL 9 is built against Red Hat Enterprise Linux 9 channels
-
rhel-9-for-*-baseos-rpms
-
rhel-9-for-*-appstream-rpms
-
codeready-builder-for-rhel-9-*-rpms
-
-
EPEL 8 is built against Red Hat Enterprise Linux 8 channels
-
rhel-8-for-*-baseos-rpms
-
rhel-8-for-*-appstream-rpms
-
codeready-builder-for-rhel-8-*-rpms
-
EPEL packages which are known to also exist in other RHEL channels
should keep a lower epoch:version-release
(EVR) than the RHEL package.
This is because packages have been known to move from these other channels into the target base channels.
Keeping a lower EVR helps ensure a smooth upgrade path.
The packages in the repository should, if possible, be maintained in similar ways to the Enterprise Packages they were built against. In other words: have a mostly stable set of packages that normally does not change at all and only changes if there are good reasons for changes. This is the spirit of a stable enterprise environment.
The changes that cant be avoided get routed into different release trees. Only updates that fix important bugs (say: data-corruption, security problems, really annoying bugs) go to a testing branch for a short time period and then are pushed to the stable branch; those people that sign and push the EPEL packages to the public repo will skim over the list of updated packages for the stable repo to make sure that sure the goal "only important updates for the stable branch" is fulfilled.
Other updates get queued up in a testing repository over time. That repository becomes the new stable branch after 2 weeks of testing. But even these updates should be limited to fixes only as far as possible and should be tested in Fedora beforehand if possible. Updated Packages that change the ABI or require config file adjustments must be avoided if at all possible. Compat- Packages that provide the old ABI need to be provided in the repo if there is no way around a package update that changes the ABI. Packages in the testing repo for 2 weeks are automatically promoted to stable. Packages with sufficient karma are also promoted to stable. Update candidates that aren’t pushed to stable after 6 months are eligible to be removed by Release Engineering.
For more information about updating EPEL packages, including minimum testing time for packages, refer to the EPEL Updates Policy.
Workflow examples / Information
-
Maintainer builds the package.
-
Maintainer submits an update for testing using bodhi.
-
If the update gets sufficient karma it is promoted to stable.
-
After 2 weeks, if the package does not have a negative karma, bodhi will promote the package to stable.
-
Pushes for both testing and stable take place daily.
Guidelines and Backgrounds for this policy
Some examples of what package updates that are fine or not
Examples hopefully help to outline how to actually apply above policy in practise.
Minor version updates
Let’s assume package foo is shipped in EPEL 8 as version 1.0.1; upstream developers now ship 1.0.2
-
build as normal, but wait at least two weeks and possibly more in testing.
A little bit bigger minor version updates
Let’s assume package foo is shipped in EPEL 8 as version 1.0.1; upstream developers now ship 1.2.0; the ABI is compatible to 1.0.1 and the existing config files continue to work
-
build as normal, but leave in testing until there is sufficient karma to go to stable.
A yet again little bit bigger minor version updates
Let’s assume package foo is shipped in EPEL 8 as version 1.0.1; upstream developers now ship 1.4.0; the ABI is compatible to 1.0.1, but the config files need manual adjustments
-
build for the stable branch is normally not acceptable; a backport should be strongly considered if there are any serious bugs that must be fixed
-
build for the testing branch is also disliked; but it is acceptable if there is no other easy way out to solve serious bugs; but the update and the config file adjustments need to be announced to the users properly — use the epel-announce list for this.
-
leave in testing if at all possible.
A major version update
Let’s assume package foo is shipped in EPEL 8 as version 1.0.1; upstream developers now ship 2.0.0; the ABI changes or the config files need manual adjustments
-
This update should be avoided if possible at all. If there really is no other way to fix a serious bug then follow the incompatible upgrades policy. In the case of a library package changing soname, consider shipping a compat package that provides the current soname at the same time you ship the new soname.
Security Updates
Security updates should be marked as such in bodhi and will be pushed to stable. Because of this you should always try and make as few changes as possible on these sorts of updates. Apply only the backported fix, or if you must, the new version that provides only the fix. Try and avoid pushing other changes with a security update.
Still unsure if a package is fine for EPEL?
Just ask on epel-devel mailing list or #epel IRC channel for opinions from EPEL members.
Why not a rolling release with latest packages like what was in Fedora Extras?
Why should we? That would be what Fedora Extras did and worked and works well for it — but that’s mainly because Fedora (Core) has lots of updates and a nearly rolling-release scheme/quick release cycle, too. But the Enterprise Linux we build against is much more careful with updates and has longer life-cycle; thus we should do the same for EPEL, as most users will properly prefer it that way, as they chose a stable distro for some reasons — if they want the latest packages they might have chosen Fedora.
Sure, there are lots of areas where having a mix of a stable base and a set of quite new packages on top of it is wanted. Maybe the EPEL project will provide a solution (in parallel to the carefully updated repository!) for those cases in the long term, but not for the start. There are already third party repositories out there that provide something in this direction, so users might be served by them already.
Further: A rolling release scheme like Fedora Extras did is not possible for many EPEL packages for another reason, new packages often require new versions of certain core libraries. This will cause problems in EPEL because we won’t be able to provide updated libs as it would replace libraries in the core OS.
Example: This document was written round about when RHEL5 got released; many packages that get build for RHEL5 can’t be build for RHEL4 at this point of time already, as the RHEL4-gtk2-Package is two years old and is too old for many current applications, as they depend on a newer gtk2. So if even if we would try to have a rolling scheme with quite new package we’d fail, as we can’t build a bunch of package due to this dependencies on libs; in the end we would have a repo with some quite new packages while others are still quite old. That mix wouldn’t make either of the "latest versions" or "careful updates only" sides happy; so we try to target the "careful updates only" sides. Remember, EPEL’s support and updates cycle is much longer then Fedora’s.
Getting Fedora packages in EPEL
Getting my Fedora package in EPEL
For your own fedora package use the
standard procedures
for requesting a new branch using fedpkg request-branch
.
Getting someone else’s Fedora package in EPEL
Packages in the EPEL repository are volunteered by Fedora packagers via requests by interested users. If a package you are looking for is not there, please follow the EPEL package request steps.
Stalled EPEL Requests
There are times that an EPEL / Fedora package maintainer isn’t responding to an EPEL package request. If a different packager would like to build and maintain that package in EPEL, these are the steps they take.
-
Anybody opens a Bugzilla bug requesting a package be added to EPEL-X. A packager (the Bugzilla reporter or another person) expresses that they are willing to help maintain / co-maintain that package in EPEL-X.
-
A week goes by with no action.
-
They re-say that they are willing to maintain / co-maintain the package in EPEL and set a needinfo flag for the maintainer.
-
This is in case the initial message was missed.
-
-
Two weeks go by with no response.
-
They file a rel-eng ticket, that points to the Bugzilla bug, requesting appropriate privileges to be able to branch and build that package in EPEL-X
-
This part of the policy will adjust as various features get implemented in pagure and dist-git.
-
-
The privileges are given and the packager is made the Bugzilla contact for EPEL.
-
They then request a branch, and build the package in EPEL-X following normal steps.
"Action" is considered something that progresses the bug. "Action" can be positive or negative. Such as a response of "The code has not been updated for 10 years and has security issues" and then they close the ticket. "No Action" could be no response at all, or it could be a response of "I do not want to do epel" and then they do nothing else.
A template for these steps can be found in the EPEL package request steps.
Distribution specific guidelines
The Fedora Packaging Guidelines are written for current Fedora releases. Sometimes there are changes in Fedora that cause the packaging guidelines there to not make sense for the older software being run in RHEL. When that occurs, we document the differences with the Fedora Packaging Guidelines on the EPEL Packaging page.
Policy for Conflicting Packages
-
EPEL packages must not conflict with packages in the target base of RHEL. See above link for a complete list of channels per RHEL Release that EPEL does not conflict with. This includes source package names due to the way that koji deals with packages from external repositories.
-
As an exception to the above rule, devel packages in EPEL that are alternate versions of devel packages in RHEL (i.e. compat packages) are allowed to conflict with each other. See the section about conflicts in compat packages for more details.
-
EPEL packages can conflict with packages in other RHEL channels outside of the target base.
-
EPEL maintainers should be open to communication from RHEL maintainers and try and accommodate them by not shipping specific packages, or by adjusting the package in EPEL to better handle a conflicting package in a channel on a case by case basis.
When a package is added to RHEL for that is already in EPEL, it usually needs to be removed from EPEL. Please follow the retirement process to do this. If the package is only available for a subset of all architectures, it might still be possible to keep the package in EPEL as described in the EPEL Packaging Guidelines.
Conflicts in compat packages
Due to the EPEL policy of maintaining backwards compatibility, EPEL has a greater need for forward compat (i.e. newer alternate version) packages than Fedora. There may also be cases where backwards compat (i.e. older alternate version) packages are needed. When creating a compat package, note that it is okay to set a Conflicts between them as noted in the Fedora Conflicts Guidelines. This is allowed both between EPEL packages and between EPEL and RHEL packages. The latter is an explicit exception to the general rule for EPEL packages to not conflict with target base RHEL packages.
Policy for Orphan and Retired Packages
EPEL follows the Fedora Policy for Orphan and Retired Packages.
Unretiring an EPEL-only package requires a re-review.
No re-review is required to unretire an EPEL branch if the package is still in Fedora.
Policy for end-of-life releases
When a RHEL release reaches the end of the Maintenance Support phase, the corresponding EPEL release also goes end-of-life. On the day maintenance support ends for the RHEL release, Koji build targets are removed, and it is no longer possible to build or distribute new EPEL packages for that release. A short time after that, the now end-of-life EPEL repository is archived, and MirrorManager is adjusted to serve that repository from the archives.
Want to help? Learn how to contribute to Fedora Docs ›