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

On Fri, 2021-05-07 at 08:36 -0400, Neal Gompa wrote:
> On Fri, May 7, 2021 at 3:37 AM Alfredo Moralejo Alonso
> <amoralej at redhat.com> wrote:
> > On Fri, May 7, 2021 at 8:07 AM Fabian Arrotin <arrfab at centos.org>
> > wrote:
> > From RDO/CloudSIG perspective, the workflow of getting EPEL
> > imported in CBS and tagging the required builds on the SIG tags
> > would work fine if resigning and redistribution is not a problem.
> > > So we have two solutions and the easiest/fastest one is probably
> > > just to
> > > import pkgs in koji and SIG can just tag-build what they
> > > want/need
> > > (including cherry-picking ENVR) but with the downside effect of
> > > pkg
> > > signed with a different gpg key (and so my original question to
> > > Fedora :
> > > is that allowed  ?)
> From the hyperscale SIG perspective, if we *must* do it this way,
> then
> we want them blocked from publishing (that is, the content *must not*
> be shipped to our repositories by default as they are effectively
> buildroot only packages) since complete compatibility with EPEL is a
> requirement.

Yeah, different SIGs will have different requirements here, which is
fine. For SIGs that are already rebuilding and redistributing content
from EPEL, and that don't require compatibility with the EPEL repos,
resigning and redistributing is going to be ok.

For SIGs like Hyperscale that want compatibility with the EPEL repos,
adding a dependency on epel-release and *not* resigning /
redistributing will be the preferred solution. I think as long as
publishing is left to the SIGs (e.g. by manually tagging the wanted
packages), it will be ok. Hyperscale will tag packages to our buildroot
tags, other SIGs will tag them to destination tags to have them
redistributed.

Once this is implemented, I recommend documenting the tradeoffs of each
approach so every SIG can choose the one that's most appropriate for
them and their users.

Cheers
davide