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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



@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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux