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