epel/docs
7
0
Fork 6
Code Pull requests 4 Projects Activity

Clarify policy on non-default modules

Browse source 
It's not technically not possible for EPEL packages to have build
dependencies on non-default module packages.  It is however technically
possible for EPEL packages to have runtime dependencies on such
packages.  Doing so is a poor user experience because the package would
fail to install by default, and would only install once a particular
module stream is enabled.  To avoid this situation, let's clarify the
policy that such runtime dependencies are not allowed.
This commit is contained in:
Carl George 2026-07-06 20:22:26 -05:00
commit 6a20481eb4
1 changed files with 7 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

13
modules/ROOT/pages/epel-policy.adoc
View file

@ -48,12 +48,7 @@ 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.
The Target Base for each distribution is defined as the CentOS/RHEL content that the Koji builders have access to.
* EPEL 10's leading minor version is built against CentOS Stream 10 repos
** `baseos`
@ -76,6 +71,12 @@ Koji builders have access to.
** `rhel-8-for-*-appstream-rpms`
** `codeready-builder-for-rhel-8-*-rpms`
Due to the technical limitations of modularity,
Koji builders do not have access to non-default module streams.
Packages from non-default module streams are excluded from the Target Base definition.
EPEL packages may conflict with or duplicate these non-default module packages.
EPEL packages must not have build-time or runtime dependencies on these non-default module packages.
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.