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.