On Wed, Jul 10, 2019 at 4:58 PM Stephen John Smoogen <smooge at gmail.com> wrote: > > > > On Wed, 10 Jul 2019 at 16:52, Thomas Oulevey <thomas.oulevey at cern.ch> wrote: >> >> Hello folks, >> >> In the planning of next Community build services, a new question came up. >> >> In the past we never allowed EPEL repositories to be used as external >> repositories for SIGs. Doing so, would allow to build against EPEL >> packages and not duplicate the work for maintainers in EPEL/SIGs. >> >> However it would mean also building against a moving target which can be >> difficult if EPEL policies are the same as today. >> > > 1. What are the policies that EPEL would need to change? > 2. What are the parts of EPEL that are a moving target compared to the continuous release method of CentOS? EPEL does not keep copies of older versions of software in the public mirrors, they discard them. This means that old dependencies for home users, or tested stable releases for production use, may evaporate without notice as new releases are published. I've been bitten by this a few times, and helped set up internal mirrors or "reposync" rathter than rsync based mirrors to keep the old packages available. EPEL is also at risk of RHEL releasing a commercial version that overlaps, especially in a commercial channel, and having to decide whether to discard the EPEL release or continue it. This is precisely what happened with ansible. It's a built-in risk, which EPEL has tried to keep under control. By the way, for others who might want to play with mock and EPEL component building early, I've published a reposync tool for RHEL 8 boxes to grab all the enabled channels at https://github.com/nkadel/nkadel-rsync-scripts/blob/master/reposync-rhel-8.sh - reposync script to buld local mirror of RHEL 8 channels on subscribed host https://github.com/nkadel/nkadel-rhel-8-mockrepo - mock and python macro RPM building tools, tested and working on RHEL 8. I'll also point out that the epel-8-x86_64.cfg, or similar configs, need the "best" option to "best=0", to resolve some of the "module" dependencies. >> As EPEL 8 is also in the making it would be good to hear what SIGs think >> about this specific issue. >> >> Let us know ! I'm not a SIG, just someone who publishes a lot of EPEL requiring ports of software