Keep or remove GlusterFS from EPEL-6?

[Stephen John Smoogen]

On 16 May 2012 18:07, Bryan J Smith <b.j.smith at ieee.org> wrote:
> Kevin Fenzi wrote:
>> My understanding from long ago when we last discussed this was:
>> EPEL will not ship anything that's available in src.rpm format under
>> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server
>> Now, some of the newer channels like RHS were not there when we
>> launched EPEL6, so if lots of people think we should revisit this, we
>> could.
>
> Stephen John Smoogen wrote:
>> 1) We decided about a year ago that if its not a SRPM in the RHEL OS
>> directory we would not count it as something we could not build
>> against.
>
> Wait.  These two seem to be in conflict, at least to me.  Kevin says
> one policy (with the possibility of revisiting), then Stephen says
> something else was decided last year.

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. That to me is the RHEL OS
directory. Kevin writes better English than I do. If gluster shows up
in that tree then it will get pulled from EPEL. If it does not show up
in there it does not.

> Stephen John Smoogen wrote:
>> This was because we would have needed to remove puppet and
>> several other tools that various RHEL layered products included at old
>> releases that we had gone past in version by the time the product was
>> released.
>
> I think Spacewalk/Satellite's inclusion of select packages is a
> general issue, at least as long as the Oracle DB is the backend (seems
> to be changing with PostgreSQL).  But those are just a few support
> packages.

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

> Now we're talking an entire entitlement offering.  ;)
>
> Stephen John Smoogen wrote:
>> 2) Using any add on repository comes at a price. EPEL can do as much
>> as it can to lower that price, but at a certain point there are going
>> to be issues.
>
> Of course.  My only point, based on 100% account experience, is that
> we're talking about conflicting with an entire entitlement offering.
> All other arguments aside (and can be discussed off-list), this means
> that Red Hat customers will have to start to consider not using EPEL
> as a result.

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. [Having had
to do this with RHN updates across a cluster made it clear that if you
are going to run something large.. making sure you know what is going
to be put on the systems is always a system administrators job.]

-- 
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me."  —James Stewart as Elwood P. Dowd