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: >> >> 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 ?) >> >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. -- 真実はいつも一つ！/ Always, there's only one truth!