On Wed, May 5, 2021 at 8:23 AM Fabian Arrotin <arrfab at centos.org> wrote: > > On 05/05/2021 14:04, Neal Gompa wrote: > > On Wed, May 5, 2021 at 7:59 AM Fabian Arrotin <arrfab at centos.org> wrote: > >> > >> On 29/04/2021 23:07, Kevin Fenzi wrote: > >>> Yeah, I think this plan sounds fine. It would require making a import > >>> script, that imports as things build in epel, but that should be > >>> do-able. > >>> > >>> kevin > >>> > >> > >> 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 > >> > >> Is that the workflow that people wanted to see ? It's true that it would > >> be easy to consume, and even cherry-pick which ENVR of a pkg to have in > >> a repo (so not be forced to upgrade to a newer epel pkg). > >> > >> If so, can we have +1 from Fedora infra/Fesco about just importing epel > >> pkgs in our koji (to not have to rebuild everything) and so also ship > >> pkgs out (but signed again with SIG gpg pub key for repoclosure in their > >> own repo) > >> > >> Searching for feedback to make progress on this request and not let it > >> fall in a hole like last time :) > >> > > > > I would probably suggest instead that we make release packages depend > > on epel-release. The package is already shipped in CentOS, so we can > > have SIG release packages also depend on it. For example, Davide and I > > are prepared already to make Hyperscale's SIG release package depend > > on epel-release. > > > > > > That would probably work for hyperscale SIG, if you just rely on > epel-release to have all Requires: pkgs available at client side .. > That doesn't solve the other request about SIGs just willing to import > one (or a few) pkg[s] to a specific version for their own SIG and still > redistribute it , instead of just rebuilding it (like they do now) .. so > original question still apply : can Fesco/Fedora allow this ? :) > > PS : due to previous infra policy, myself I had to spend time rebuilding > pkgs from epel7/8 to have these available for infra tags , while for a > majority of the cases, just tagging an existing epel build would be > enough and so win of time .. > I don't think this is a good solution, but nothing stops you from importing them and resigning them for your own distribution. I think you're overthinking this and supporting a use-case that SIGs should not be allowed to do. They already can't do this for CentOS base, it should be treated similarly for EPEL, in my opinion. The general user expectation is that CentOS content should *all* be compatible with EPEL and vice versa. Breaking that expectation creates a source of agony for users. -- 真実はいつも一つ！/ Always, there's only one truth!