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

Mon May 10 23:52:49 UTC 2021
Nico Kadel-Garcia <nkadel at gmail.com>

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.