On 24/04/2020 15:59, lejeczek via CentOS-devel wrote:
CloudSIG repos are not created nor tested to work with EPEL.
Yet they should be. Everything should be tested and should take as much advantage of EPEL as possible, as EPEL is for almost every "regular" scientific/small,large/business/education - and whichever other names one could come up with - environment, the must-have repo. If SIGs do not start crawling out their "special" closets and do not work with EPEL tightly then the rest of us will continue to suffer constant packages conflicts. Stuff collides way too often! Or rid of EPEL altogether and just give us a consistent & stable software repositories.
Among other reasons CloudSIG support several stable releases which require different dependencies versions and EPEL is single rolling release.
There is a reason for not including EPEL in e.g CloudSig or Opstools: EPEL is not gated and as Alfredo already mentioned, a rolling release.
There was a time when cloud SIG relied on EPEL, but e.g an all test days we organized for real people to test new deployments, then EPEL was broken; for various reasons: person a upgraded puppet, person b pushed a broken build, etc. etc. Coming from that experience, I would not pull it in and rather contribute to a CentOS SIG to have more control on the content; it is easier and more reliable to handle upgrades there.
IMHO EPEL is something you can use; but if you do, understand that every fedora packager can push their packages to EPEL. There are rules, but not all packagers care about the upgrade policy. I totally understand, where you are coming from, but EPEL is too unstable in my experience.
Matthias