<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 7, 2021 at 8:07 AM Fabian Arrotin <<a href="mailto:arrfab@centos.org">arrfab@centos.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 05/05/2021 17:21, Davide Cavalca via CentOS-devel wrote:<br>
> On Wed, 2021-05-05 at 13:59 +0200, Fabian Arrotin wrote:<br>
>> I started to rsync/pull epel7/8 pkgs for x86_64,aarch64,ppc64le on a<br>
>> temporary place and we can start testing importing pkgs.<br>
>><br>
>> *but* it's where it needs probably a little bit of clarification :<br>
>> while<br>
>> initial request was to just have access to EPEL pkgs to satisfy<br>
>> Requires: and/or BuildRequires: I'm wondering about a redistribution<br>
>> policy (if any) for pkgs built on fedora infra and that SIGs would be<br>
>> able to just redistribute if they tag such pkg in their own tag<br>
>> (mostly<br>
>> for -{testing,release}).<br>
>><br>
>> Each pkg tag for -release would go out on mirror CDN, but signed with<br>
>> SIG gpg key<br>
> <br>
> I can think of one downside of this: it would result in packages with<br>
> the same ENVR, but different signatures and checksums. I know this<br>
> would be a problem for FB (due to how some of our internal tooling<br>
> works), but I'm not sure what other side effects it could bring. If we<br>
> go down this path, would it be possible to *not* resign the packages,<br>
> and just leave them signed with the EPEL key?<br>
> <br>
<br>
Well, pulling/rsync EPEL signed pkgs and import in cbs is "easy" but<br>
yeah, the current signing pipeline would just (as it was designed for<br>
that particular case) sign pkgs in a tags with the SIG gpg key, and not<br>
have "exceptions"<br>
So if that's considered an issue to have epel pkgs signed again with SIG<br>
gpg key in *their* repositories, we should revisit the original RFE.<br>
<br>
The other solution is then : use EPEL as external repo in koji so that<br>
pkgs depending on (Build)Requires: at build time would find pkgs and so<br>
build .. but that would mean :<br>
- such SIG would probably have a dep on epel-release if other EPEL pkgs<br>
are needed at runtime (probably the case if it was needed also at buildtime)<br>
- no way for SIG to stick to a particular ENVR (and if they want to, -<br>
thinking about RDO/openstack cloud sig- they'd probably rebuild epel<br>
pkgs in their tags, like they are doing for some years now ...)<br>
<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So we have two solutions and the easiest/fastest one is probably just to<br>
import pkgs in koji and SIG can just tag-build what they want/need<br>
(including cherry-picking ENVR) but with the downside effect of pkg<br>
signed with a different gpg key (and so my original question to Fedora :<br>
is that allowed  ?)<br>
<br>
-- <br>
Fabian Arrotin<br>
The CentOS Project | <a href="https://www.centos.org" rel="noreferrer" target="_blank">https://www.centos.org</a><br>
gpg key: 17F3B7A1 | twitter: @arrfab<br>
_______________________________________________<br>
CentOS-devel mailing list<br>
<a href="mailto:CentOS-devel@centos.org" target="_blank">CentOS-devel@centos.org</a><br>
<a href="https://lists.centos.org/mailman/listinfo/centos-devel" rel="noreferrer" target="_blank">https://lists.centos.org/mailman/listinfo/centos-devel</a><br>
<br>
</blockquote></div></div>