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