[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Keep or remove GlusterFS from EPEL-6?

Niels de Vos wrote:
> They are not under the "os" directory where most packages live:
> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/
> It may not be a problem for binary derivatives of RHEL if they don't provide glusterfs packages.
> But this may be a problem for people who use the Red Hat Storage bits.

Far be it from me to interpret policy, so I'll just point how this
comment nails the reality, and let others with the project decide.

I.e., ask yourself ...
Is the Fedora Project's EPEL just for community "EL Rebuilds" and derivatives?
Or is EPEL for all, including the customers of the Fedora Project's
sponsor, Red Hat?

Alan Pevec wrote:
> Why do they need to have EPEL repo enabled? Doesn't that make them unsupported?

Again, here's the reality, and I'll let others with the project decide ...

Yes, major Red Hat accounts tap EPEL, often bringing in the the EPEL
YUM repository into their RHN Satellite Server.  It saves them having
to build all sorts of upstream community solutions.  And yes, of
course, these components in EPEL are _unsupported_.  But they remove
not just a lot of the overhead of customers building-their-own, but
the policies and other advantages of the Fedora Project itself can be

Leaving them in EPEL means that Red Hat customers now must clone and
segment out the conflicting bits.  Although many accounts end up
cloning channels into "internal releases" so the test EPEL components,
it's still going to add to their workload.

And with that all said, as I understand it, one of the reason for the
EPEL guidelines were so Red Hat customers would not have conflicting
components in EPEL that are also available from RHN.  Two, conflicting
sets of packages on the same server, that is really, really
_unsupported_, and causes headaches for Red Hat services and support.
I.e., sometimes it takes a bit before this "root cause" is discovered
(first hand experience speaking here).  ;)

Which brings me to the final point, which is non-technical ...

Marginalizing Red Hat customers, ones who fund a lot of what Red Hat
does upstream (and downstream as well), is not probably the best move
for the longevity of the Fedora Project, or "EL Rebuilds" who rely on
Red Hat's continued funding.  This should be obvious to many here, but
I understand there might be some community members here who may not
see this immediately (hence why I'm pointing it out).

Again, far be it from me to interpret policy, but to me, if it is in a
RHN channel, it makes more sense for downstream "EL Rebuilds" to fetch
the source, rebuild, and include it in their redistributions.  Any
time one goes down the route of asking, "well, is this really OS?"
ignores the fact that it is available from RHN, and will affect
customers of Red Hat.  Red Hat is more than an open source OS, and
even more than just platform components.

Otherwise it is going to get really ugly for Red Hat customers, and
EPEL will lose its value with them.  That's really a case no one
should want to see, as it will affect everyone, not just Red Hat and
its customers.  Of course, I could be biased.  ;)

Bryan J Smith - Professional, Technical Annoyance

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]