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). John _______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
