Re: [EPEL-devel] Mock/Copr default epel-8-* configuration to be changed

[Nico Kadel-Garcia]

@Miroslav Suchý asked me to sum up my suggestions for using internal
mirrors more clearly, So, adding to his published Google Doc:

5 - Use internal RHEL mirrors.

It's difficult to license multiple RHEL releases and enable multiple
yum dnf or yum channels and supported RHEL or CentOS releases and
architectures on a single server. Instead, support a local repository
with "reposync" used to mirror RHEL channels for designated
architectures and releases as needed. It is possible to mount DVD
images for local copies of specific releases to ease the mirroring
process.

Pros:
    Provides multiple RHEL channels, architectures, and distributions
as desired.
    Allows locking streams for scheduled updates of build environments
for compatibility inaccessible to streaming releases.
    Allows aggregated, rather than directly mirrored, EPEL repos to
avoid regression failures.

Cons:
    Requires local storage space and web server for registered clients
to load new content.
    Requires individual tuning for distinct local environments
    Adds RPM provenance concerns for local repos.

6. Use snapshotted CentOS 8 Stream mirrors

The CentOS 8 Stream uncertainties are described above. Creating a
local CentOS 8 mirror with locked snapshots can help stabilize the
stream, update the build components only if and when an update is
scheduled.

Pros:
    Reduces burden of multiple build hosts on upstream mirrors.
    Allows site specific scheduling of build repo updates.
    Allows easy and efficient rsync internal mirrors.
    Allows aggregated, rather than directly mirrored, EPEL repos to
avoid regression failures.

Cons:
    Reposync based mirrors for RHEL require more work.
    Includes inevitable phase lags between upstream changes and local
snapshotted repos..
    Reduces, though does not completely eliminate risk of CentOS 8
Stream regression errors

[EPEL-devel] Mock/Copr default epel-8-* configuration to be changed

[Kevin Kofler]

Nico Kadel-Garcia wrote:
>  5 - Use internal RHEL mirrors. 
This is inherently not an acceptable solution for the default mock 
configuration shipped to end users, because they will not have access to 
those internal mirrors (and I doubt Red Hat will allow making them public, 
as it would bypass their whole subscription mechanism).

>  6. Use snapshotted CentOS 8 Stream mirrors 
That can work if you make the mirrors public (which should not run into 
legal issues as in the previous point). But the main issue there is that (as 
already pointed out several times) a CentOS Stream snapshot is in general 
not binary-compatible with a RHEL point release. Add to that the maintenance 
effort. So I really do not see the value this provides over just using Alma 
or Rocky.

        Kevin Kofler