Some EPEL thoughts (was Re: perl-Net-Telnet both in EPEL and RHEL)

Michael Stahnke mastahnke at gmail.com
Sat Aug 9 02:50:06 UTC 2008


Could we add this to the next steering committee meeting?  Here are the issues:

1.  "Layered" products, such as cluster server, ship some support
packages like perl modules, etc.  Should those be allowed in EPEL?
They are not part of core RHEL.  IMHO, as much software as possible
should be available for everybody.  At my place of employment, if I
need a package and it's not in EPEL, I then have to build/maintain my
own, which is what EPEL hopes to stop.  I could see the EPEL committee
denying some 'core' packages of each layered channel, (such as RHDS
core packages, cluster server core packages for RHEL 4, etc).

2.  Even competing with layered products seems bad.  If we would like
RHX to have the same packages as in EPEL but be able to buy support
for them, shouldn't RH do the same?  That way the software is
available to those who would like to preview it, use it with CentOS,
Scientific, etc.  I realize this contradictory to what EPEL started
with, but our goal should be software to everybody, at least that's
what I think.

3.  What about products such as Free IPA vs IPA, Fedora DS vs RHDS,
Spacewalk vs Satellite etc?  If there is a fully open offering, can we
put it in EPEL and not officially be 'conflicting' with the RH channel
for it?

4. Firmware packages that are on the supplemental EL discs.  To me,
this is just to make some hardware work, shouldn't that be easily
available?  As an enterprise customer, it'd be a lot easier to have it
in EPEL (which I am going to use anyway) than to have to
download/import the supplemental disc.

I am sure there are more questions and conflicts, and I don't want to
stomp on Red Hat, but I would like to make EPEL as usable and complete
as possible.


PS I won't be the EPEL meeting Monday.


stahnma




More information about the epel-devel-list mailing list