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. Specifically: - it does not require rebuilding EPEL onto CBS (which would defeat the entire purpose of this exercise) - it gives SIGs autonomy of decision on whether to consume content from EPEL, rebuild it or ignore it, on a per-package basis - 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) - 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. Cheers Davide