Keep or remove GlusterFS from EPEL-6?

Mark Chappell tremble at tremble.org.uk
Thu May 24 06:54:10 UTC 2012


On 23 May 2012 23:18, Stephen John Smoogen <smooge at gmail.com> wrote:
> The issue is that if EPEL pulls out core packages every time Red Hat
> decides to offer a sub-channel of supported, then there is no need for
> EPEL since it will get gutted regularly.

>From what I recall, we had basically decided to ship rebuilds of the
Red Hat RPMs where EPEL would end up gutted due to RPMs getting pulled
out of the middle of dependency trees where Red Hat were shipping in a
side repository that wouldn't be available to all: for example the
Perl dependency trees that had one or two low level perl libraries
that only appeared in the desktop/client offerings.

I do not think that we should be shipping things like the gluster
core, but, I think ripping out the dependencies as well is simply
going to result in EPEL becoming worthless as Red Hat slowly offers
more Add-On channels and pulls in library based dependencies from the
bottom of EPEL offered dependency trees.  Maybe we need to speak to
someone from product management about how Red Hat could make more of
these dependencies available in something like the optional channels,
with minimal support, so that paying customers get the Red Hat RPMs
and the support, and those that don't pay for the additional
entitlements just have access to the libraries.

As someone working heavily with RHEL and Satellite, while we do import
the entirety of EPEL into Satellite we only move the RPMs into a used
channel that we specifically want to use.  It's a little extra work
but does also mean that we control our own bake off period.  Essential
with 1000s of servers.


Mark




More information about the epel-devel-list mailing list