Keep or remove GlusterFS from EPEL-6?

Niels de Vos devos at fedoraproject.org
Wed May 23 15:15:21 UTC 2012


On Mon, May 21, 2012 at 10:33 PM, Dennis Gilmore <dennis at ausil.us> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, 16 May 2012 14:32:23 +0200
> Niels de Vos <devos at fedoraproject.org> 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?
>
> So i think here its up to the gluster team what they want to do.  For
> instance Satellite has pulled in a bunch of EPEL packages and ship them
> in satellite. things like cobbler, koan, perl modules and various other
> bits and pieces. they pull them in with the intention of them remaining
> in EPEL. I believe some of the other layered products do this also,  I
> think that something that ships in a layered product should be shipable
> in EPEL but if the layered product asks us to remove it we should do
> so. most/all layered products are only available with additional
> subscriptions. which limits the availablity and AFAIK CentOS Scientific
> Linux etc dont ship all layered products.

My main concern is that different versions of GlusterFS (3.2.x vs
3.3.x) are not compatible. It will not be possible to use the EPEL
3.2.x version to mount a volume with the native GlusterFS protocol
from the Red Hat Storage 2.0 (RHS) appliance which is based on
GlusterFS 3.3.x. The previous release called Red Hat Storage Software
Appliance 3.2 (RHSSA) uses GlusterFS 3.2...

One release or the other would have problems :-/

Niels


> Dennis
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.18 (GNU/Linux)
>
> iEYEARECAAYFAk+6pogACgkQkSxm47BaWfd9nACeKByMR80SBjW6x71jZoXgEZXC
> qT0AoKpnIA/k6cFz19B8KqPlavb+umEU
> =BIv5
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list




More information about the epel-devel-list mailing list