On Tue, Nov 23, 2021 at 9:16 PM Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Nico Kadel-Garcia wrote: > > Neither of those have much track history. > > Of course they don't. How can they, when CentOS had stolen their show for > years and the sudden "change of directions" was announced only earlier this > year? Blame RH for not having given the rebuild community more time to > prepare. (Pulling the plug on CentOS 8 7-8 years before its originally > announced EOL was a huge surprise, and not a good one.) > > > The easy move is to use CentOS 8 Stream for "mock", at least in the short > > term. > > With CentOS Stream, you want to use epel-next, not plain epel. And the epel- > next configs already use CentOS Stream. Which is available. It would need to be designated as the "default" for compilation. The changes would be in the default settings for mock-core-configs, nowhere else, and not require other repo changes. > > The alternative is to designate the CentOS switch to streaming > > deployments as a non-starter, and re-invent point releases on top of > > CentOS 8 Stream It's likely to create small discrepancies with > > packages released, and rejected or withdrawn, from CentOs 8 Stream > > before they get to RHEL 8. Since CentOS 8 Stream is the new beta for > > RHEL 8, this would seem inevitable. > > Why would we want to reinvent the wheel instead of using one of the two > already working solutions? And how would that not necessarily have even less > "track history", considering that Alma and Rocky already exist, whereas your > idea has not even be started yet? I'm not saying this is the best option, but it invelves less change to the build systems to rely on mirrors and base repos that Red Hat does not own. It's feasible as a technology, and it's something that some of us are going to have to do anyway to use CentOS for production deployments. I've been doing something like it since... well, since Red Hat 9 in 2003, and for Fedora, to lock down static internal mirrors for staged rather than streaming updates. > > It's a waste of time and resources to generate and manage the relevant > > repodata, exacerbated by the multiple unwelcome and randomly > > overlapping channels of CentOS 8. Multiple snapshots of a repo are > > also not free in disk space or inodes. > > Of course it is. So do not do that. Assess the alternatives before discarding them. > > But I'm not sure if the more "replicate only" distributions will be > > long-lived multi-platform enough to rely on for EPEL, > > Then you switch to another rebuild. The demand is not going to vanish > overnight, so I do not expect them to go away without a replacement, just as > CentOS did not go away without a replacement either. That is *expensive* to do. It leads to people discarding distributions, which I observe has been happening for CentOS and RHEL. Some previous fans are biting the bullet and switching to Ubuntu to avoid this mess, others are switching to Amazon Linux or simply skipping RHEL 8 and CentOS 8 entirely. Amazon, for example, is not planning to publish a matching "Amazon Linux 3", I've asked them. Unfortunately, Amazon Linux 2 is too divergent from RHEL and CentOS to be usable for EPEL, it's python 3.7 instead of python 3.6. _______________________________________________ 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
