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.
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?
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.
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.
and I'd expect screaming from various security and support experts if EPEL relies on anything not directly published by Red Hat.
Well, for the local mock config, that is exactly what had happened until CentOS got absorbed by Red Hat. And if Red Hat does not leave us with a better option, blame Red Hat.
I'm finding myself sad that Scientific Linux withdrew from publishing new releases in deference to CentOS.
Me too. They too got burned by Red Hat's misleading adoption of CentOS and the following surprise "change of directions", and it is unfortunate that they have decided against resurrecting Scientific Linux given the change. But Scientific Linux was "not directly published by Red Hat" either.
Kevin Kofler