Keep or remove GlusterFS from EPEL-6?

[Greg Swift]

So I did respond below.  But I also went to go reference something in
the guidelines and now I'm confused.  This looks to be clearly stated
in the Guidelines and Policy:

http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy_for_Conflicting_Packages
c
EPEL packages must never conflict with packages in RHEL Base
(Including Advanced Platform).
EPEL packages can conflict with packages in other RHEL channels. <--------

How does that not specifically address this?

-greg

On Wed, May 16, 2012 at 7:07 PM, Bryan J Smith <b.j.smith at ieee.org> wrote:
> 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?
no. not at all.  That being said, its a community project, the
community wanted it in EPEL (obvious from its existence).  Many times
a community trying out software can lead to them wanting support for
that software.  It was a general statement that Red Hat can benefit,
not that they should specifically pursue the concept for any of their
software.

> If so, what is the purpose of Red Hat evaluations of add-on
> entitlements for Red Hat customers?

1) RH add-on software is sometimes a different version than the
community version
2) Some people have policies against external repository use
3) Its more 'professional' for RH to present their evaluation channel
when talking to people less comfortable with the concept of upstream
being an applicable evaluation (IMO)

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

I never said that the Red Hat provided add-on == the EPEL built one
(although in theory they would be very similar).  The EPEL provided
build would be the Fedora community provided build.  Nothing more than
it ever has been.

> 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.
I am a RH customer that contributes to EPEL. I also don't use CentOS,
or Scientific or any other redistribution of RH.  Just so my viewpoint
is clear as well.

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

Valid point.   But Satellite doesn't complain about software using the
same namespace?  I know our Sat admin tells us it does... so that
might be something to consider. See also Steven's point

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

Leaning on Steve's response... at some point the system administrators
need to be aware of their system.   I know that I'd be aware of this.

I also think that the understanding that the base repository is the
primary conflict point seems to be very valid.