On 09/14/2012 12:13 AM, R P Herrold wrote: > 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 That is because upstream refined their offering into multiple - even sometimes conflicting ! - channels ( RHDirServ in the example you had the kindness to provide) and not all of them are taken into account by EPEL. OTOH the EPEL guidelines are getting refined and I am 100% sure and ready to bet on a case of fine beer that the people who will see conflicts between EPEL and [base] are not among those who need the convenience of having the epel-release rpm shipped by CentOS. And even if they were, they will know how to solve them. And they would also point them to EPEL for proper solving. It happened in the past and conflicting packages were removed when needed. > 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 beg to differ here. As long as we clearly specify that we just SHIP the release rpm for users' convenience but not ENDORSE and that ALL support is to be taken from EPEL, I am sure that people will understand. A polite "please ask for help in #epel or on the epel mailing list" will definitely be all that is needed.