On Sat, 26 May 2012 12:24:14 -0400
Jon Stanley <jonstanley(a)gmail.com> wrote:
I agree with the sentiment, but it can help that even without
explicitly avoiding every single bit of package overlap.Do I think
that EPEL should ship a new kernel, coreutils, etc? Of course not. But
I don't think that EPEL should be categorically prohibited from
shipping something that overlaps with something else that is not RHEL
that Red Hat sells. I consider the layered entitlements (including
cluster and lb) to *not* be a part of RHEL - they are part of a
different product, sold and priced differently (the fact that you have
to have the base product in order to buy the layered ones makes no
difference either - I have to have a car, or else buying floormats
doesn't make any sense).
So to put it in concrete terms, I advocate that EPEL does not ship
anything that is in -server and -server-optional. Anything else is
fair game, unless explicitly asked by Red Hat to remove the bits.
I have been lurking along for a while here but I would like to put in
I think Jon's proposal above:
inclusive of what epel's default limits are, disallowing of exact
rebuilds of any srpm from any channel and allowing for notification
from red hat through a specific and established source (his example
of spot is a good one but we don't need to necessarily throw spot
under the bus, other folks could be the epel-go-between too)
is a good proposal. I think it is consistent, easy to understand and to
explain and will help epel thrive.
my 2cents. I speak only for me not for my employer.