Overlap policy v20120615

[inode0]

On Sat, Jun 23, 2012 at 2:55 PM, inode0 <inode0 at gmail.com> wrote:
> 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).

To make something of a concrete proposal I think it is logical and
easy to understand if we treat HA/LB/RS/SFS in the same manner as they
are all delivered to RHEL customers in the same manner. There are two
obvious choices for what manner they will be treated.

(1) Disallow conflicts with these packages in EPEL. The upside is that
EPEL users know they won't have conflicts with any of these packages
from Red Hat. The downside is that it prevents other packages from
being included in EPEL that have dependencies from this package set.

(2) Allow conflicts with these packages in EPEL. The upside is more
software available in EPEL, both from these channels and from other
packages with dependencies on packages in these channels. The
downside, conflicts for RHEL customers who use these channels
directly. Conflicts can be minimized by careful versioning here.

Some folks will object strongly to both of those options, I believe
they already have objected. So maybe there is a place to meet in the
middle?

(3) Allow packages from these channels into EPEL as dependencies for
other packages using careful versioning to minimize conflicts with
those who subscribe directly to these channels. This will allow more
software into EPEL, reduce dependency failures for those not
subscribing to these channels and minimize conflicts with those who
do.

John