Keep or remove GlusterFS from EPEL-6?

Bryan J Smith b.j.smith at ieee.org
Thu May 17 00:07:47 UTC 2012


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.

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.

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's all I was pointing out.  To me, the policy, as Kevin stated it
exists today, makes sense.  To do otherwise would be for EPEL to start
marginalizing Red Hat customers.  This works in no one's best
interest.

Stephen John Smoogen wrote:
> EPEL is a volunteer effort done in spare time of both Red Hat and non-Red Hat
> employees. Our price for using our product is that people step up to
> fix things when they are broken.

As are all Fedora Project efforts.  As I said, I'm continually
thankful for the continued efforts of such maintainers.  But I'm also
concerned with what I'm seeing here.  I.e., I'd have to start advising
against EPEL for Red Hat customers as  a result.

Greg Swift wrote:
> So as a RHEL, Gluster, and EPEL customer/user I have to say that I see
> the benefit of it being in EPEL.  There is even a benefit to Red Hat
> (first hit is free kinda thing) with Gluster staying in EPEL.

Whoa!
Are you suggesting EPEL be an "evaluation" for Red Hat add-on entitlements?

If so, what is the purpose of Red Hat evaluations of add-on
entitlements for Red Hat customers?
And for those who are not using Red Hat products, for those using "EL
Rebuilds" for that matter?

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?

In fact, some of my initial concerns here (again, 100% thinking of the
Red Hat customers I have been at that use EPEL) has only been further
justified by statements not only like the one above, but other
statements such as ...
  "and if we stop, we're taking something away from the community"

I think some are really, really getting off-track here with these
types of statements -- so much so that I don't want to respond further
in public.  I only wanted to put forth how this affects Red Hat
customers who use/contribute to EPEL.  Understand that's 100% of my
viewpoint, and not anything else.

Greg Swift wrote:
> But isn't there a technical solution to this. Is this what yum priorities
> is all about?  Why doesn't the epel-release package require
> yum-{,plugin}-priorities and set the priority of all EPEL repositories
> lower than the standard one.  In theory the policy itself implements
> this, but it doesn't negate the usefulness of backing up the policy
> with config.
> It also can provide a benefit for groups that may mirror some EPEL
> packages to a local repository.   If the internal system ends up with
> the local repository and EPEL attached (for various reasons I'm not
> going to delve into) then the internal one would win because its
> unlikely that anyone would set the priority lower than the EPEL by
> default (although not beyond realm of possibility, but you can't save
> everyone).

And if they mirror EPEL into, say, a RHN Satellite Server channel, how
do they know all of what to filter out from EPEL because it's
conflicting with RHN packages?  Especially when the packages are newer
than the RHN ones.

Understand they won't be loading the epel-release package on to their
systems, so they don't have the yum prorities it includes.  Now the
customer could go in add them, and setup their channels and related
solutions, clone selectively, etc..., but should they have to deal
with more added management?

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.

If not, then I'd have to move to change my recommendations on EPEL at
Red Hat customers.  It's just my opinion, but I think this changes the
project in a way that benefits no one.  Again, I understand the new
entitlement offering is causing this consideration.  But that will
always happen, as customer requirements for support and certification
options will in the future too.


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




More information about the epel-devel-list mailing list