Keep or remove GlusterFS from EPEL-6?

[Stephen John Smoogen]

On 23 May 2012 14:54, Bryan J Smith <b.j.smith at ieee.org> wrote:
> Stephen John Smoogen wrote:
>> I think that for customers using layered products it would be smarter
>> to avoid outside repositories anyway.
>
> That would then remove the value of an option from the Fedora
> community like EPEL.  That's why I asked prior what the purpose of
> EPEL is, regardless of any prior assumptions or statements.  If it is
> going to deliver layered products, I will have to advise enterprises
> of those details.

Well here is the issue. We have been delivering layered products for a
long time (probably since the beginning) mainly because various groups
did not want to do an Emerging Technologies for Enterprise Linux.

>> If a customer is using layered items onto the OS they are going to need
>> to make sure they have only Red Hat supported software installed.
>
> So that now brings up another question ...
>
> If they only have the base entitlement product installed, this is not the case?
> I.e., if they have no layered products, they can use EPEL.  But if
> they do, they can't?
>
> And if we have difficulty with that question, is it really Extra
> Package for Enterprise Linux (EPEL) any more?

Hey they can use whatever they want.  It is up to entities I have no
say or control in whether it will be supported by either consultants
or Red Hat support.

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. At this point we are looking
at 1/3->1/2 of EPEL having to be removed because packages require or
buildrequire items that are included in layered products that would no
longer be available to build against. Which leads me to my first
statement, that the usability of EPEL to a layered user is much less
than a base OS user.

>> Even if we were to somehow remove all the conflicts we can't remove
>> secondary problems where software if it finds libXYZ installed will manually
>> load that even if it is not included with RHEL.
>
> Ideally layered products should push any libraries, those shared
> between or utilized between layers, into the base OS for support.
> That way there is no question what should and should not conflict with
> a Fedora SIG like EPEL, assuming the guidelines are to avoid such.
>
> I stress "ideally" because we all know how long any product release
> considerations, let alone changes, take to verify countless items and
> make those types of decisions.
>
>> [Various gnome apps do this so I expect other software will also end up
>> with such "plugin" architectures.]
>
> Indeed.  But then we run into the related issues where Fedora is more
> leading edge, and EPEL uses something more leading edge.  But there
> are still some customers who want those additional plug-ins for the
> trailing edge versions in RHEL or its layered products, but those
> plug-ins do not ship with them.
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list



-- 
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