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

Thu Apr 29 11:09:40 UTC 2021
Fabian Arrotin <arrfab at centos.org>

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:


-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab