On Mon, Nov 22, 2021 at 9:01 AM Pavel Raiskup <prais...@redhat.com> wrote: > > Hello Fedora EPEL maintainers! > > First I don't feel comfortable announcing this, I'm not happy about the > situation and so I don't want to be the lightning rod :-). But I believe > that we can come to acceptable Copr/Mock solution and this needs to be > discussed... so here we are. > > By the end of the year 2021 we have to fix our default EPEL 8 Mock > configuration (mock-core-configs.rpm, /etc/mock/epel-8-*.cfg) as CentOS 8 > goes EOL by then. > > The same thing needs to happen in Fedora Copr, with the epel-8-* chroots > (side note, in Fedora Copr we use the mock-core-configs package for builds > without any deployment specific modifications). > > I am proposing (as PR against mock upstream ATM [1]) to switch the default > epel-* configuration from CentOS+EPEL to RHEL+EPEL as soon as possible > (see the pull request [1]).
This would seem to be an exceptionally bad idea. Red Hat elected to force this CentOS Stream release structure down everyone's throats unannounced, compelling default mock behavior to use the stream is a logical consequence. Trying to outsmart Red Hat on this is going to break EPEL dependencies and keep breaking EPEL for Stream deployments. > This would bring some consequences, namely newly with epel-8* chroots, > > - builds will require a valid Red Hat subscription (the no-cost variant is > OK as well, though [2]) > - we will miss some build-time packages that Red Hat is not shipping, at > least at the beginning till they are added (to RHEL CRB, or other > currently unknown place). > - cross-arch compilation can not be used, Red Hat subscriptions don't > allow that (using QEMU and rpm --forcearch), [3] Which is precisely why pointing it to the 'stream' release seems the only workable solution. > The positive thing is that the default configuration will be much closer > to the official EPEL builds (because Fedora Koji EPEL builds are actually done > also against RHEL). That does seem desirable. Frankly, I don't expect this mid-stream pivot to last more than 2 years: it was tried before with Red Hat 9, and discarded thoroughly for RHEL 2.1. Point releases are too useful for environments that cannot afford CI/CD with the underlying operating system, and don't want to spend the time re-inventing point releases themselves. > For the Fedora Copr builders, we already have the necessary Red Hat > subscriptions in hand (will be deployed by the end of the year). So we will > only loose the opportunity to build on emulated epel-8-armhfp permanently, and > epel-8-s390x temporarily (as we already work on the native s390x support). > > Any thoughts? Feedback is needed here. > > [1] https://github.com/rpm-software-management/mock/pull/802 > [2] https://rpm-software-management.github.io/mock/Feature-rhelchroots > [3] https://bugzilla.redhat.com/show_bug.cgi?id=1912847 > > Pavel > > > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
