Overlap policy v20120615

inode0 inode0 at gmail.com
Sat Jun 23 19:55:35 UTC 2012

On Fri, Jun 15, 2012 at 2:26 PM, Toshio Kuratomi <a.badger at gmail.com> wrote:
> On Fri, Jun 15, 2012 at 12:43:52PM -0500, inode0 wrote:
>> So the build system is os+optional+lb+ha+rs+other stuff I don't recall
>> if I understood previously but EPEL only prohibits shipping packages
>> from os+optional+lb+ha. I'm wondering why the restriction against
>> shipping packages isn't just os+optional here.
> My understanding is that the buildsystem is os+optional+lb+ha which is the
> set of channels that we are saying we won't conflict with.  In my view, that
> part should always remain consistent.

Ok, and that seems to pretty much map to what was included on the
RHEL5 distribution media in the side repos for Cluster,
ClusterStorage, and VT. On the RHEL6 distribution media there are side
repos for HighAvailability (overlaps Cluster in el5), LoadBalancer
(overlaps Cluster in el5), ResilientStorage (overlaps Cluster and
ClusterStorage in el5), and ScalableFileSystem (not distributed on any
media for el5 that I am aware of currently).

> This doesn't address the "How do I tell if a package shipped by Red Hat
> Channel Foo can be added to EPEL?" question.

So from looking at this from the perspective of distribution media I
would say the current exclusion of HA/LB does logically map in spirit
to what was included in Cluster/ClusterStorage in el5. The part that
isn't so logical is allowing ResilientStorage. That seems to be in the
same category as Cluster/ClusterStorage to me since it overlaps with
those packages. Not sure what makes sense with ScalableFileSystem but
protecting against conflicts there as well seems most consistent to me
(that is the XFS userspace stuff).


More information about the epel-devel-list mailing list