Keep or remove GlusterFS from EPEL-6?

[Steve Traylen]

On May 16, 2012, at 2:32 PM, Niels de Vos wrote:

> Hello,
> 
> in #gluster on Freenode, we discussed a little if GlusterFS is allowed in EPEL-6. EPEL-5 is not affected as Red Hat does not provide packages for GlusterFS on RHEL-5.
> 
> The policy that may forbid GlusterFS in EPEL-6:
> https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy mentions "packages from EPEL should never replace packages from the target base distribution - including those on the base distribution as well as layered products".
> 
> The Red Hat Storage product that includes GlusterFS is like an appliance. Customers who buy a subscription get access to a DVD download of RHEL-6.2.z (Extended Update Support, EUS) with the packages from an additional RHN-ChildChannel. It is not possible/intended/supported to use this RHN-ChildChannel without installing your system from the "Red Hat Storage" DVD. Therefore this RHN-ChildChannel is a little different from other layered products.
> 
> The first time a Red Hat product that includes GlusterFS was released in November 2011. EPEL-6 already contained the GlusterFS packages. The EPEL-policy was not harmed, but now GlusterFS is made available by Red Hat, and it is possible to have two sources for GlusterFS (one being EPEL-6, the other through the Red Hat Storage ChildChannel).
> 
> The question I have now:
> Is it needed to block the glusterfs package from EPEL-6? Even if most RHEL users will not have access to EUS channel(s) that contain the glusterfs packages?
> 

My understanding is that glusterfs does not (and preferably for me at least) should not be removed: 

http://fedoraproject.org/wiki/EPEL/FAQ#How_can_I_know_which_packages_are_part_of_RHEL.3F

states what packages should be considered as a conflict, .. I thought some where was page that
exactly dealt with the extra RHEL streams however the Guidelines link you posted suggest I may be wrong though
given the binary derivatives don't genrally distribute these  extra streams its a bit of a tall order.

See:


> Thanks,
> Niels
> 
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list