Packaging Guidelines and Policies for EPEL

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.

If too many show up, put them into a separate document.

Just ask on epel-devel mailing list or #epel IRC channel for opinions from EPEL members.

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.

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.

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

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.

Per RHEL Release Package Conflict Channel Exclusions

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.

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.

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.

When a RHEL release reaches the end of the Maintenance Support phase RHEL life cycle , 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. A short time after that, the now end of life EPEL repository is moved to archives and mirrormanager is adjusted to serve that repository from archives.