On Mon, May 10, 2021 at 12:09 PM Johnny Hughes <johnny at centos.org> wrote: > > On 5/7/21 8:15 AM, Matthew Miller wrote: > > On Fri, May 07, 2021 at 08:07:12AM +0200, Fabian Arrotin wrote: > >> 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 ?) > > > > I don't *think* that would be a problem. It's too bad RPMs can't have > > multiple signatures. > > > > But wouldn't cherry-picking ENVR cause problems if a system has EPEL > > enabled? > > > > I personally think the best option is just to use the EPEL repos as > external repos and to require epel-release in repos where you require > epel package to be installed. > > That way they remain totally independent and we don't have multiple > copies of the same rpms and ENVRs with different signatures / keys. "But Bullwinkle! That trick never works!" More seriously, the difficulty is that EPEL discards the older packages from the public repos, especially previous releases of the same package or packages that are then brought into CentOS. This happened with ansible and many python modules, and it became quite awkward to find and revert to those previous RPMs for specific package releases. And if you've never encountered the nightmare that can be python dependency resolution with the less integrated or out of date modules over at pypi.org, expected to work with one published yesterday, then good luck to you, sir. It's therefore common place to set up an internal repository that only aggregates from EPEL, and never deletes content, until after a major Red Hat based OS is entirely discarded. It's why I publish reposync wrapper tools over at github.