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.