EPEL acceptance policy

Warren Togami wtogami at redhat.com
Tue Mar 13 21:18:59 UTC 2007


Tim Burke wrote:
> I'm wondering if people may misinterpret that to think that things not 
> on the base RHEL isos are fair game for replacement.  Layered products 
> from RH which are delivered separately from the OS come to mind.  
> Another example would be packages which are only intended for certain 
> release variants.  For example, the GFS cluster components are not 
> available to desktop / client configurations - server only.
> 
> Tying to think of an alternative recommended wording:
> 
> "thus packages from EPEL should never replace packages delivered by Red 
> Hat - including those on the base distribution as well as layered 
> products."

A few months ago Daniel Riek, Jesse Keating and theorized an easy to 
understand policy to recommend for EPEL.

Layered products themselves are not duplicated in EPEL.  EPEL provides 
layer repos that are built upon and require a corresponding RHEL layer.
	
(these are not actual layer names, just examples)

EPEL5 Bar requires RHEL5 Bar
EPEL5 Foo requires RHEL5 Foo
EPEL5 requires RHEL5 base

Where the user chooses to use an EPEL layer, they must have the 
underlying layer from some source.

Red Hat cannot stop an external project from building clone layers. 
This layered repo recommendation tries to be a clearly understood and 
fair compromise that recognizes this reality.

I hope EPEL can accept something like this as in the EPEL5 policies.

Warren Togami
wtogami at redhat.com




More information about the epel-devel-list mailing list