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