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
> [email protected]
> https://www.redhat.com/mailman/listinfo/epel-devel-list


_______________________________________________
epel-devel-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/epel-devel-list

Reply via email to