[CentOS-devel] Shipping an EPEL release

Thu Sep 13 17:49:43 UTC 2012
Johnny Hughes <johnny at centos.org>

On 09/13/2012 10:32 AM, Karanbir Singh wrote:
> hi guys,
> 
> One bit of feedback at LinuxCon this year from people was that we should
> ship epel with a lower barrier to entry. And I have mixed feelings about
> that. But I wanted to know what everyone else thinks about :
> 
> 1) Shipping epel-release in CentOS-Extras, so its installable, usable
> out of the box.
> 
> 2) Shipping epel-release in the distro itself, with the epel repos's
> enabled=false. This is the option that most people seem to want, but I
> am least keen on.
> 
> 3) do nothing, leave things as they are.
> 
> Ofcourse, if we do either (1) or (2) we would need to set some sort of a
> baseline standard that allows other repo's to be included as well ( as +
> if they meet the baseline standard )
> 
> regards,
> 

I think that we should not include those repos by default.  If we do, we
now have to worry if they change their release files, etc.

I surely would not want it in the main distro ... maybe in extras.  But
I don't see that as much of an advantage unless we have it enabled by
default.  If we do this, we will have to maintain a release file for the
repos that is different from their own release files.  This will render
the documentation that they have on their websites in error OR require
them to change it and make it different for CentOS as compared to RHEL
(that is, you must enable it if you isntalled it from here, but not if
you installed it from us, etc.)

I see no reason to include this in CentOS unless what we include is
exactly what is released by the repo itself, so that it works the same
whether installed by our repo or theirs.

So, my vote is 3 ... and maybe 2, but not disabled as an option.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20120913/8c84bb87/attachment-0007.sig>