Keep or remove GlusterFS from EPEL-6?

Bryan J Smith b.j.smith at ieee.org
Wed May 23 20:54:59 UTC 2012


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.

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

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




More information about the epel-devel-list mailing list