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

Mike McGrath mmcgrath at redhat.com
Mon Aug 11 01:04:21 UTC 2008


On Fri, 8 Aug 2008, Michael Stahnke wrote:

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

Don't those already ship as part of CentOS?  Maybe we should just send
people to CentOS if they want them but don't want to pay for them?

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

I'm curious about the future of RHX as well.  Many of the groups in RHX
have made a comittment to Open Source but that doesn't mean getting some
of those packages playing well with the Fedora/EPEL model will be easy.

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

I'd think absolutely it could be in if it is non-conflicting.

	-Mike




More information about the epel-devel-list mailing list