[CentOS-devel] Making EPEL available in CBS for SIG builds

Fri Apr 30 14:21:41 UTC 2021
Johnny Hughes <johnny at centos.org>

On 4/29/21 6:09 AM, Fabian Arrotin wrote:
> On 29/04/2021 00:07, Davide Cavalca via CentOS-devel wrote:
>> On Wed, 2021-04-28 at 23:15 +0200, Fabian Arrotin wrote:
>>> Just some links to previous threads about this :
>> (cut)
>>> So worth reading the three threads and then revisit it maybe ? :)
>> Thanks Fabian, this is really helpful. I actually think the proposal
>> you had made back then in 
>> https://lists.centos.org/pipermail/centos-devel/2019-July/073860.html
>> would work well for this, and addresses most of the concerns I've seen
>> raised throughout those threads.
> Great, I'd like to have other SIGs opinions too but that's a good start
> ! :-)
>> Specifically:
>> - it does not require rebuilding EPEL onto CBS (which would defeat the
>> entire purpose of this exercise)
> Yes ! :-)
>> - it gives SIGs autonomy of decision on whether to consume content from
>> EPEL, rebuild it or ignore it, on a per-package basis
> That was indeed the idea : each SIG can tag-build for -testing/-release
> the version they want
>> - because EPEL is continuously imported and versions that are consumed
>> are tagged, this also solves the "yum downgrade" problem -- even if
>> EPEL upstream moves on, older versions that were consumed in CBS would
>> remain available (unless one untags them explicitly)
> Yes, idea (as explained below) would be to create internal tag just for
> this and people can tag-build from that tag in their SIG tag[s]
>> - OTOH, if a SIG does want to track the latest versions available in
>> EPEL, that is also possible (e.g. Hyperscale would like this as it
>> would expose potential breakage early on)
>> One potential issue I don't have a clear sense of is the matter of
>> conflicting NVRs that was raised in
>> https://lists.centos.org/pipermail/centos-devel/2019-July/073863.html .
>> This is not a concern for Hyperscale as we set a custom disttag, but it
>> could be for other SIGs that don't do this and also rebuild packages
>> present in EPEL with the same NVR.
> Reason why we'd have a consensus on doing this and properly communicated.
> If we decide to just import existing builds into cbs (can be an internal
> tag that will never be pushed out for obvious reasons), that will work
> for pkgs with different ENVR, but not for existing ones. So if SIGs
> applied some patches before rebuilding an epel pkg, they'd be more than
> encouraged to do this at the EPEL level.
> For the others, they can just carry on with existing pkgs and next time,
> just 'tag-build' the import EPEL packages to satisfy Requires: or
> BuildRequires:

I would LOVE to make the EPEL repos available to build against in the
CentOS buildroots.  I think it is a solid idea.

The problem obviously is, that is not how RHEL is done now.  It could be
how it is done for Stream and RHEL in the future.  This is a great place
to discuss the benefits and problems with this idea.

Certainly for SIGs, I see no reason not to do it for CBS and/or any
other SIG building location.