Keep or remove GlusterFS from EPEL-6?

[Bryan J Smith]

On Wed, May 16, 2012 at 8:25 PM, Dennis Jacobfeuerborn
<dennisml at conversis.de> wrote:
> Is it possible to create an "EPEL-extended" repo? That seem to be the
> logical solution. Keep EPEL completely collision free and push packages
> like GlusterFS into "EPEL-extended" that users can enable in the repo config.

You mean like CentOS Extras?  ;)

I.e. you're sorta agreeing with me, that's why I made my point (just
's/CentOS Extras/EPEL-extended/g') ...

  'Case-in-point ...
   I mean, this sounds more and more like EPEL will be something more
   difficult to manage at Red Hat customers as if they tapped ... say ...
   CentOS Extras for example.  Again, I must be really missing something,
   because I really thought the guidelines were designed to avoid such,
   so EPEL is what it is.'

Just 's/EPEL/EPEL-extended/g' and it fits.  Of course, that still come
back to ...

  'Is the purpose of EPEL to be the location where both Red Hat customers
   and users of "EL Rebuilds" can go to have an unified, free binary (as
   in beer) set version of a Red Hat add-on entitlement?'

CentOS with its Extras option addresses this.  Scientific Linux has
its options.  There are many "EL Rebuilds" that have many options.  As
always, my view was 100% from the standpoint of being at Red Hat
customers, and having to deal with this.

On Wed, May 16, 2012 at 8:30 PM, Stephen John Smoogen <smooge at gmail.com> wrote:
> No I think we are talking about the same thing. Just saying it
> different ways. If it is not in
> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server
> then it is ok to be built and shipped ...

My sincerest apologies.

> I don't believe it was Spacewalk. It was MRG and another product line
> that caused us to rethink the issue.

Oh, there have been several.  Even JBoss EAP throws a curve with EPEL too.  ;)

> That was happening before with different entitlements. While I
> disagreed originally I have come to agree with DAG's advice. Anyone
> who links directly to an outside repository for production systems
> needs to really rethink how they do system administration.

And I don't disagree with DAG at all.  In fact, I have to preach this
to Red Hat customers regularly too.  But EPEL used to be something
that ensured certain guidelines.  It's the one repository I didn't
have to worry about X, Y and Z, even if some other conflicts would
arise (unlike DAG, CentOS Extras, etc...).

So in this case, now that we have identified such a case (even though
the change was caused by Red Hat creating an add-on entitlement), it
still doesn't remove the considerations for Red Hat customers, per the
guidelines (at least if I understand them correctly).


--
Bryan J Smith - Professional, Technical Annoyance
http://www.linkedin.com/in/bjsmith