[CentOS-devel] Shipping an EPEL release

[R P Herrold]

On Thu, 13 Sep 2012, Brian Mathis wrote:

> This may not be a big issue for EPEL, since they aim to "never
> conflict with or replace packages in the base Enterprise Linux
> distributions", but maybe this becomes part of the baseline standard
> for CentOS.

1. EPEL has been going through an effort to figure out where 
it fits, because upstream's proliferation of side products, 
and the main product upstream 'moving in' matter both from 
EPEL and from elsewhere.  It is undeniable that this has 
caused it some heartburn to the EPEL folks -- consult its 
mailing list and IRC channel meeting logs for the last 6 
months for details

The predicate assumption:
 	that they aim to "never conflict with or replace packages in
 	the base Enterprise Linux distributions"

is no longer durably accurate, any more.  In looking at a 
mirror I maintain of SRPMS of upstream and of EPEL that I 
keep, I see:

./epel/6/SRPMSonly/released/SRPMS/389-admin-1.1.29-1.el6.src.rpm
./epel/6/SRPMSonly/released/SRPMS/389-admin-console-1.1.8-1.el6.src.rpm
./epel/6/SRPMSonly/released/SRPMS/389-adminutil-1.1.15-1.el6.src.rpm
./epel/6/SRPMSonly/released/SRPMS/389-console-1.1.7-1.el6.src.rpm

and

./redhat/rhel/SRPMSonly/6Server/en/RHDirServ/SRPMS/389-admin-1.1.25-1.el6.src.rpm
./redhat/rhel/SRPMSonly/6Server/en/RHDirServ/SRPMS/389-admin-console-1.1.8-1.el6.src.rpm
./redhat/rhel/SRPMSonly/6Server/en/RHDirServ/SRPMS/389-adminutil-1.1.14-1.el6.src.rpm
./redhat/rhel/SRPMSonly/6Server/en/RHDirServ/SRPMS/389-console-1.1.7-1.el6.src.rpm
./redhat/rhel/SRPMSonly/6ComputeNode/en/os/SRPMS/389-ds-base-1.2.10.2-20.el6_3.src.rpm
./redhat/rhel/SRPMSonly/6Server/en/RHDirServ/SRPMS/389-ds-console-1.2.6-1.el6.src.rpm

so not only does EPEL duplicate upstream's offerings, it 
would appear to displace them in some cases and side products. 
This is messy, and there is little reason to fight this fight

I understand CentOS presently may not have coverage of all at 
the upstream 6 series SRPMs, but that seems to me to be a more 
valuable way to consider moving, than pre-adding the archive 
of another project (EPEL) that is well-documented, and trivial 
as to installation.  After all it is: install a package via 
RPM, and accept a key ... takes perhaps a minute


2. Also, EPEL is quite large -- 3815 SRPMs in their 6 tree, by 
last night's count.  As such there are huge number of 
potential interactions that somehow will become CentOS 
responsibility sort out in the main IRC channel, because 
'well, you shipped the configs' if we were to proceed to add 
them -- so, independently a bad idea

I would not be in favor of adding EPEL stanzas, even if not 
enabled

-- Russ herrold