From Fedora Project Wiki
m (1 revision(s))
mNo edit summary
 
(56 intermediate revisions by 20 users not shown)
Line 1: Line 1:
= Packaging Guidelines and Policies for EPEL =
'''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.)


{{autolang|base=yes}}


= Packaging Guidelines and Policies for EPEL =


The packages in EPEL follow the Fedora Packaging and Maintenance
The packages in EPEL follow the Fedora Packaging and Maintenance Guidelines --
Guidelines -- that includes, but is not limited to the
that includes, but is not limited to the [[Packaging:Guidelines| packaging
[[Packaging/Guidelines| packaging guidelines]] , the
guidelines]], the [[Packaging:NamingGuidelines|package naming guidelines]] and
[[Packaging/NamingGuidelines| package naming guidelines]] , the
the [[Packaging:ReviewGuidelines|package review guidelines]] that are designed and maintained by
[[Packaging/ReviewGuidelines| package review guidelines]] and the
the [[Development/SteeringCommittee| FESCo]] and
[[Extras/Policies|  packaging policies]]  that are designed and
[[Packaging/Committee|Packaging Committee]]. EPEL-specific exceptions are documented here
maintained by the [[Development/SteeringCommittee| FESCo]] and
and in the [[EPEL:Packaging]] page.
[[Packaging/Committee| Packaging Committee]] . There are however some
EPEL-specific exceptions, which you can find below.


Please note that the sections "Guidelines" and "Policies" use their
Please note that the sections "Guidelines" and "Policies" use their
Line 37: Line 39:
repository should, if possible, be maintained in similar ways to the
repository should, if possible, be maintained in similar ways to the
Enterprise Packages they were built against. In other words: have a
Enterprise Packages they were built against. In other words: have a
mostly stable set of packages that normally to not change at all and
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
only changes if there are good reasons for it -- so no "hey, there is
a new version, it builds, let's ship it" mentality.
a new version, it builds, let's ship it" mentality.
Line 49: Line 51:


EPEL packages should only enhance and never disturb the Enterprise
EPEL packages should only enhance and never disturb the Enterprise
Linux distributions they were build for. Thus packages from EPEL
Linux distributions they were built for. Thus packages from EPEL
should never replace packages from the target base distribution -
should never replace packages from the target base distribution -
including those on the base distribution as well as layered products;
including those on the base distribution as well as layered products;
kernel-modules further are not allowed, as they can disturb the base
kernel-modules further are not allowed, as they can disturb the base
kernel easily.
kernel easily.
In EPEL 8 or later, it is permitted to have module streams which contain
packages with alternate versions to those provided in RHEL. These packages
may be newer, built with different options, or even older to serve
compatibility needs. These MUST NOT be the default stream -- in every
case, explicit user action must be required to opt in to these versions. If the
RHEL package is in a RHEL module, then the EPEL module must have the same
name as the RHEL module, and a different stream name than the RHEL module.
Any exceptions to the module name and stream name must be approved by the
EPEL Steering Committee.
In EPEL8 or later, it is also 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-7 is built against Red Hat Enterprise Linux 7 channels
** rhel7-server
** rhel7-rhel-extras
** rhel7-server-ha
** rhel7-server-optional
* EPEL-8 is built against Red Hat Enterprise Linux 8 channels
** rhel-8-baseos
** rhel-8-appstream
** codeready-builder-for-rhel-8
** centos-8-devel
* EPEL-8-Next is built against CentOS Stream 8 repos
** baseos
** appstream
** powertools
Packages which are known to be in other Red Hat Enterprise Linux channels should be maintained in a similar fashion to limited architecture packages. The package should be gotten from the upstream (either ftp.redhat.com for RHEL-6 or git.centos.org for RHEL-7) and maintained with a NEVR less than that of the Red Hat Enterprise Linux release. This is because packages have been known to move from a Workstation channel to a server channel and backing out a package can be problematic.


The packages in the repository should, if possible, be maintained in
The packages in the repository should, if possible, be maintained in
Line 71: Line 105:


Other updates get queued up in a testing repository over time. That
Other updates get queued up in a testing repository over time. That
repository becomes the new stable branch after one month of testing. There
repository becomes the new stable branch after 2 weeks of testing.  
will be a short freeze time period before the monthly update happens
But even these updates should be limited to fixes only as far as possible and should
to make sure the repository and its packages are in a good shape -- packages
in this phase still can be removed if thats is needed. But even this
updates should be limited to fixes only as far as possible and should
be tested in Fedora beforehand if possible. Updated Packages that
be tested in Fedora beforehand if possible. Updated Packages that
change the ABI or require config file adjustments must be avoided if
change the ABI or require config file adjustments must be avoided if
somehow possible. Compat- Packages that provide the old ABI need to be
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
provided in the repo if there is no way around a package update that
changes the ABI. Packages in the testing repo that contain dependency
changes the ABI. Packages in the testing repo for 2 weeks are automatically
issues or where the maintainer doesn't feel they are stable will be
promoted to stable. Packages with sufficient karma are also promoted to stable.
held back from the stable push.


When a new quarterly update is released, EPEL will wait until the CentOS
When a new quarterly update is released, EPEL will wait until the CentOS
version of that update is available. At that time, a stable push will
version of that update is available.
be done to pull in tested packages from testing, and the stable repository
 
will be linked to the current quarterly release version.
For more information about updating EPEL packages, including minimum testing time for packages, refer to the [[EPEL_Updates_Policy|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 ===
=== Guidelines and Backgrounds for this policy ===
Line 101: Line 139:
upstream developers now ship 1.0.2
upstream developers now ship 1.0.2


* build for the stable branch only if it fixes serious bugs
* build as normal, but wait at least two weeks and possibly more in testing.
* build for the testing branch is acceptable if the upstream release is mostly a bugfix release without new features and the package got run-time testing


===== A little bit bigger minor version updates =====
===== A little bit bigger minor version updates =====
Line 110: Line 147:
the existing config files continue to work
the existing config files continue to work


* build for the stable branch only if it fixes a really serious bug
* build as normal, but leave in testing until there is sufficient karma to go to stable.
* build for the testing branch is acceptable if it fixes serious bugs


===== A yet again little bit bigger minor version updates =====
===== A yet again little bit bigger minor version updates =====
Line 120: Line 156:


* 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 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 -- say in form of release notes that get published together with the quarterly announcement.
* 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 =====
===== A major version update =====
Line 128: Line 165:
files need manual adjustments
files need manual adjustments


* this update should be avoided if possible at all. If there really is no other way out to fix a serious bug then it rare cases it might be acceptable to build the new version for the testing branch and mention the update and the needed adjustments in the release notes for the next update. An additional compat- packages with the old libs is necessary if the ABI changed.
* This update should be avoided if possible at all. If there really is no other way to fix a serious bug then follow the [[EPEL_incompatible_upgrades_policy|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.
 
===== Playground =====
 
Starting with EPEL 8, we have a [[EPEL/Playground | playground area called epel-playground.]]  The guidelines for the epel-playground area are in their own document.


===== Add more examples as they show up =====
===== Add more examples as they show up =====


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


=== Still unsure if a package is fine for EPEL? ===
=== Still unsure if a package is fine for EPEL? ===
Line 166: Line 213:
released; many packages that get build for RHEL5 can't be build for
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
RHEL4 at this point of time already, as the RHEL4-gtk2-Package is two
years old and is to old for many current applications, as they depend
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
on a newer gtk2. So if even if we would try to have a rolling scheme
with with quite new package we'd fail, as we can't build a bunch of
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
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
repo with some quite new packages while others are still quite
Line 176: Line 223:
much longer then Fedora's.
much longer then Fedora's.


=== How will the repository actually look like? ===
{{Anchor|nomaintainerresponse}}
 
=== Getting Fedora packages in EPEL ===
 
==== Getting my Fedora package in EPEL ====
 
Look [[Getting_a_Fedora_package_in_EPEL|here for the procedure used to get a Fedora package in EPEL]].


Similar to what [ http://ftp-stud.fht-esslingen.de/pub/Mirrors/centos/ layout]  CentOS uses. Rough example:
==== Getting someone elses Fedora package in EPEL ====


<pre>
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 look at https://bugzilla.redhat.com and see if a request has been opened for your package to be built. If it hasn't, please open a new ticket. Some packages may not be able to built in EPEL due to missing deps which need to be added.
* epel/                         # topdir
* 4/                           # topdir for EPEL4
* 4 -> 4.5                    # symbolic link to latest version
* 4.1/                        # this tree of course will never exists, as this is history, and is here just to show the example
....                          # 4.2, 4.3, 4.4; those won't ever exists, too
* 4.5/                        # 4.5, latest version
* 4.6                        # not yet
* ....                        # time will come
* testing/                    # testing repo, all packages go here for testing. If no dependency issues or maintainer holds,


* 5/                           # topdir for EPEL5
==== Stalled EPEL Requests ====
* 5 -> 5.0                    # symbolic link to latest version
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.
* 5.0/                        # 5.0, latest version
* 5.1                        # not yet
* ....                        # time will come
* testing/                    # testing repo, all packages go here for testing. If no dependency issues or maintainer holds,
</pre>


Each repo always has all the packages in it; hardlinks will be used to
* Anybody opens a bugzilla 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.
keep the space requirements on the server-side limited, as most
* A week goes by with no response
packages won't change.
* They re-say that they are willing to maintain / co-maintain the package in EPEL
** This is just incase the initial message was missed.
* A week goes by with no response
* They file a [https://pagure.io/releng/issues/ rel-eng ticket], that points to the bugzilla, 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.


{{Anchor|nomaintainerresponse}}
=== Distribution specific guidelines ===
=== EPEL branching if Fedora maintainer does not react ===
The [[Packaging:Guidelines| 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.


If an EPEL maintainer wants to get a Fedora package into EPEL he should check the [[EPEL/ContributorStatus|  ContributorStatus]] document.
[[Category:EPEL]]


If the Fedora maintainer of the package has indicated a desire not to participate in EPEL then the proposed EPEL maintainer can request the branch directly via the standard procedures (e.g. via bugzilla currently).  The proposed EPEL maintainer should CC the Fedora maintainer on the branch request, so the Fedora maintainer knows that the package is maintained in EPEL as well.
== Policy for Conflicting Packages ==


If it is unclear if the Fedora maintainer of the package intends to participate in EPEL then the proposed EPEL maintainer should mail the Fedora
[[EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F|Per RHEL Release Package Conflict Channel Exclusions]]
maintainer and ask about their plans for EPEL in general and the package at hand.  If there is no answer within seven days the proposed EPEL maintainer
is free to request the EPEL branch and become the EPEL Maintainer (CC the Fedora maintainer here as well).  If the Fedora maintainer decides not to be
active in EPEL they should be added to the CC list for all bugs  so that collaboration can happen where a bug effects Fedora and EPEL.


If the Fedora maintainer later decides to participate in EPEL, Then the Fedora maintainer will become co-maintainer for EPEL. (Of course co-maintainership can be extended to Fedora)
* EPEL packages must never conflict with packages in RHEL Base (Including Advanced Platform). See above link for a complete list of channels per RHEL Release that EPEL does not conflict with. This includes the source package name due to the way that koji deals with packages from external repositories.
* EPEL packages can conflict with packages in other RHEL channels.
* 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.


=== Distribution specific guidelines ===
When a package is added to RHEL for that is already in EPEL, it usually needs to be removed from EPEL. Please follow the [https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/ 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#Limited_Arch_Packages|EPEL Packaging Guidelines]].


==== EL4 ====


* EPEL4 Python packages should manually depend on the proper python version that it was build for. Most old FC-3 python packages should still use this trick.
=== Conflicts in compat packages ===


== Package Maintainer Details ==
Due to the EPEL policy of maintaining backwards compatibility, EPEL has a greater need for forward compat packages than Fedora.  When creating, a compat package, note that it is okay to set a Conflicts between them as noted in the [[Packaging:Conflicts#Compat_Package_Conflicts |Conflicts Guidelines]].  At this time, this is only allowed for packages overriding packages in EPEL, not in RHEL Base.


This section covers helpful information and guidelines for package maintainers.


=== Involve Employers: Packaging as a Job Duty ===
== Policy for Orphan and Retired Packages ==


Many packagers maintain packages that are useful for their employer.  EPEL encourages these maintainers to get their packaging role including in their job description. Having it in the job description means the packaging role can survive a packager changing jobs and not taking the package along. To help with this, EPEL has written a [[EPEL/PackageMaintainer/GenericJobDescription| generic job description]]  that you can use as the basis for amending other job descriptions.
EPEL follows the [https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_packages/ 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
[[Category:EPEL]]
if the package is still in Fedora.

Latest revision as of 20:02, 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.)

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 the EPEL SIG 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 SIG 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 - including those on the base distribution as well as layered products; kernel-modules further are not allowed, as they can disturb the base kernel easily.

In EPEL 8 or later, it is permitted to have module streams which contain packages with alternate versions to those provided in RHEL. These packages may be newer, built with different options, or even older to serve compatibility needs. These MUST NOT be the default stream -- in every case, explicit user action must be required to opt in to these versions. If the RHEL package is in a RHEL module, then the EPEL module must have the same name as the RHEL module, and a different stream name than the RHEL module. Any exceptions to the module name and stream name must be approved by the EPEL Steering Committee.

In EPEL8 or later, it is also 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-7 is built against Red Hat Enterprise Linux 7 channels
    • rhel7-server
    • rhel7-rhel-extras
    • rhel7-server-ha
    • rhel7-server-optional
  • EPEL-8 is built against Red Hat Enterprise Linux 8 channels
    • rhel-8-baseos
    • rhel-8-appstream
    • codeready-builder-for-rhel-8
    • centos-8-devel
  • EPEL-8-Next is built against CentOS Stream 8 repos
    • baseos
    • appstream
    • powertools

Packages which are known to be in other Red Hat Enterprise Linux channels should be maintained in a similar fashion to limited architecture packages. The package should be gotten from the upstream (either ftp.redhat.com for RHEL-6 or git.centos.org for RHEL-7) and maintained with a NEVR less than that of the Red Hat Enterprise Linux release. This is because packages have been known to move from a Workstation channel to a server channel and backing out a package can be problematic.

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.

When a new quarterly update is released, EPEL will wait until the CentOS version of that update is available.

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

Playground

Starting with EPEL 8, we have a playground area called epel-playground. The guidelines for the epel-playground area are in their own document.

Add more examples as they show up

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

Still unsure if a package is fine for EPEL?

Just ask on EPEL developers mailing list or #epel on freenode.org for opinions from EPEL SIG 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

Look here for the procedure used to get a Fedora package in EPEL.

Getting someone elses 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 look at https://bugzilla.redhat.com and see if a request has been opened for your package to be built. If it hasn't, please open a new ticket. Some packages may not be able to built in EPEL due to missing deps which need to be added.

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 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 response
  • They re-say that they are willing to maintain / co-maintain the package in EPEL
    • This is just incase the initial message was missed.
  • A week goes by with no response
  • They file a rel-eng ticket, that points to the bugzilla, 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.

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

Per RHEL Release Package Conflict Channel Exclusions

  • EPEL packages must never conflict with packages in RHEL Base (Including Advanced Platform). See above link for a complete list of channels per RHEL Release that EPEL does not conflict with. This includes the source package name due to the way that koji deals with packages from external repositories.
  • EPEL packages can conflict with packages in other RHEL channels.
  • 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 packages than Fedora. When creating, a compat package, note that it is okay to set a Conflicts between them as noted in the Conflicts Guidelines. At this time, this is only allowed for packages overriding packages in EPEL, not in RHEL Base.


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.

Retrieved from "https://fedoraproject.org/w/index.php?title=EPEL/GuidelinesAndPolicies&oldid=633933"