[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: EPEL acceptance policy

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 redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]