epel

#356 EPEL retirement policy and RHEL Extensions
Closed: Nothing to do by carlwgeorge. Opened by mizdebsk.

Closed: Nothing to do
Reopen Issue

The existing EPEL policy requires that when a package becomes part of RHEL, it must be retired from EPEL to avoid overlap and duplication. However, it is not clear whether this rule applies to the newly introduced RHEL Extensions channels.

The RHEL Extensions channels are quite new addition to the RHEL content model. Unlike BaseOS and AppStream, which form the core of the RHEL distribution and are enabled by default, Extensions is an optional, add-on repository. It provides additional RHEL components that are delivered separately from the core repositories and are not enabled by default on a standard RHEL installation. Users can choose to enable the Extensions repository as needed, but it is not part of the base RHEL configuration.

This raises a question about the applicability of the EPEL retirement policy in this context. When a package is added or moved into the RHEL Extensions channel, does it count as being "in RHEL" for the purposes of EPEL retirement? In other words, should maintainers remove an EPEL package if it is added to Extensions, or does the policy only cover packages added to the core RHEL repositories (like BaseOS and AppStream)?

Clarification on this point would help maintainers understand whether and when to retire packages that overlap with RHEL Extensions, and would ensure consistency in how the policy is applied going forward.

From my perspective: No. We only intend one of Extensions or EPEL to be enabled at one time, and we rely on EPEL as a source of content for some things in Extensions.

Removing packages from EPEL should only happen for the base repositories listed in the existing policy.

I think for the purposes of Fedora EPEL, we should consider RHEL Extensions a non-entity.

The only way we could reasonably consider this different is if Extensions results in proper maintainership by RHEL engineers, the repository is included in CentOS Stream by default, and the content is exported and included by default. RHEL specific addon repositories are already ignored currently, and Extensions is no different in this regard.

I want to second Brian and Neal's thoughts and comments.

No. When a package is put into RHEL Extensions is should NOT be removed from EPEL.

And as Neal said, RHEL Extensions should be a "non-entity".

The reason Neal is saying that is because in the EPEL policy it states that if a package is in one of the RHEL channels, it "should keep a lower epoch:version-release (EVR) than the RHEL package."
But that is not the case for the RHEL Extensions. If a package is put into RHEL Extensions, the EPEL package maintainer should continue to maintain that package as they usually did.

[1] - https://docs.fedoraproject.org/en-US/epel/epel-policy/

Not to mention, RHEL Extensions isn't a default channel and nobody using RHEL extensions is signing up to be a proper maintainer of that package. Without that, it's hard to argue that we should consider RHEL Extensions inclusion as a reason to retire a package from EPEL.

Therefore, for our purposes, RHEL Extensions does not exist.

Thank you everybody for your input in this matter. Is there any action to take, like documenting that package being in RHEL Extensions does not count as being "in RHEL"?

IMO, this is already documented.

https://docs.fedoraproject.org/en-US/epel/epel-policy/#_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.

Later in that section the target base distribution is clearly defined as baseos, appstream, and crb. There are already many other additional RHEL repos that are not enabled by default that EPEL is allowed to conflict with (and indeed already does). Extensions is just another repo like that.

If you feel that Extensions needs to be mentioned explicitly, I think the best place for it would be in the FAQ.

https://docs.fedoraproject.org/en-US/epel/epel-faq/
Edited by carlwgeorge

I'm happy to review a PR that adds an FAQ entry for this, but we don't need to hold this issue open waiting for that.

Metadata Update from @carlwgeorge:
- Issue close_status updated to: Nothing to do
- Issue status updated to: Closed (was: Open)

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/epel/steering/issues/356

Please continue any further discussion there.
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.