Packages duplicated between EL-5 sub-channels and EPEL

[David Juran]

On Mon, 2010-01-18 at 02:52 -0500, Jon Stanley wrote:
> On Mon, Jan 18, 2010 at 2:41 AM, David Juran <djuran at redhat.com> wrote:
> 
> > Sorry, what I meant was that the release number should be lower in EPEL.
> > I.e. the EPEL package would be identical to the RHEL one except that the
> > release number would be lower.
> 
> Generally with a package like 389 or something, you'll have a NEWER
> version in EPEL than what is in the layered product channel, as EPEL
> carries the upstream source. not the released source of the RH product
> - therefore, unless development is stagnant (which one certainly hopes
> is not the case), then the version in EPEL is necessarily going to be
> newer than that in the respective RHN channel.
> 
> Am I missing something incredibly obvious here?

Maybe the point is moot now after Friday's meeting (which I didn't
attend due to real-life interference) but this really raises the
question, what is the purpose of EPEL?
  
*) Is it to provide cutting edge versions of layered products on top of
RHEL? Isn't running plain Fedora a better choice then? Of course I see
the point in getting more people to test e.g. the latest greatest 389
version. But is that really the primary mission for EPEL? And maybe it
still can be done by creating e.g. a 389-ds package (under the name
389-ds and taking care of file system conflicts) that doesn't conflict
with redhat-ds. 

*) Is it to provide layered products to those not willing to pay for Red
Hat support? Isn't that the mission of CentOS? 

*) Is it to provide Extra Packages for Enterprise Linux (-: 
  I.e. a set of packages that for various reasons are not included in
RHEL but are in Fedora. That does not really imply that the version of
that extra package should be the latest end greatest version. In my
opinion, the package version in EPEL should mirror the stable policy of
RHEL by preferring stability over cutting-edge.

-- 
David Juran
Sr. Consultant
Red Hat
+358-504-146348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20100118/c53d764d/attachment.sig>