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

On Fri, May 7, 2021 at 8:07 AM Fabian Arrotin <arrfab at centos.org> wrote:

> On 05/05/2021 17:21, Davide Cavalca via CentOS-devel wrote:
> > On Wed, 2021-05-05 at 13:59 +0200, Fabian Arrotin wrote:
> >> I started to rsync/pull epel7/8 pkgs for x86_64,aarch64,ppc64le on a
> >> temporary place and we can start testing importing pkgs.
> >>
> >> *but* it's where it needs probably a little bit of clarification :
> >> while
> >> initial request was to just have access to EPEL pkgs to satisfy
> >> Requires: and/or BuildRequires: I'm wondering about a redistribution
> >> policy (if any) for pkgs built on fedora infra and that SIGs would be
> >> able to just redistribute if they tag such pkg in their own tag
> >> (mostly
> >> for -{testing,release}).
> >>
> >> Each pkg tag for -release would go out on mirror CDN, but signed with
> >> SIG gpg key
> >
> > I can think of one downside of this: it would result in packages with
> > the same ENVR, but different signatures and checksums. I know this
> > would be a problem for FB (due to how some of our internal tooling
> > works), but I'm not sure what other side effects it could bring. If we
> > go down this path, would it be possible to *not* resign the packages,
> > and just leave them signed with the EPEL key?
> >
>
> Well, pulling/rsync EPEL signed pkgs and import in cbs is "easy" but
> yeah, the current signing pipeline would just (as it was designed for
> that particular case) sign pkgs in a tags with the SIG gpg key, and not
> have "exceptions"
> So if that's considered an issue to have epel pkgs signed again with SIG
> gpg key in *their* repositories, we should revisit the original RFE.
>
> The other solution is then : use EPEL as external repo in koji so that
> pkgs depending on (Build)Requires: at build time would find pkgs and so
> build .. but that would mean :
> - such SIG would probably have a dep on epel-release if other EPEL pkgs
> are needed at runtime (probably the case if it was needed also at
> buildtime)
> - no way for SIG to stick to a particular ENVR (and if they want to, -
> thinking about RDO/openstack cloud sig- they'd probably rebuild epel
> pkgs in their tags, like they are doing for some years now ...)
>
>
>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  ?)
>
> --
> Fabian Arrotin
> The CentOS Project | https://www.centos.org
> gpg key: 17F3B7A1 | twitter: @arrfab
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20210507/561a89d1/attachment.html>