On Sat, Jun 23, 2012 at 2:55 PM, inode0 <ino...@gmail.com> wrote: > On Fri, Jun 15, 2012 at 2:26 PM, Toshio Kuratomi <a.bad...@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 _______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
