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