[CentOS-devel] Community build services and EPEL8

Thu Jul 11 11:50:16 UTC 2019
Nico Kadel-Garcia <nkadel at gmail.com>

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