Am 19.12.20 um 18:49 schrieb Nico Kadel-Garcia:
On Sat, Dec 19, 2020 at 12:29 PM Matthew Miller mattdm@mattdm.org wrote:
On Sat, Dec 19, 2020 at 04:34:53AM -0500, Mark Mielke wrote:
- Minor release milestones to stabilize branches. We have breakage
with most minor release upgrades, and the stabilization process is an important method of isolating users from being affected by this. This is why CentOS 8 Stream is being said "for developers", while RHEL 8 would be "for production". It is being said, because it is a real thing. If you truly believed minor release milestones were unnecessary for CentOS 8 Stream, then you would also believe that minor release milestones were unnecessary for RHEL 8.
It's important to note that the CentOS Linux rebuild never actually had this. RHEL minor releases are actually branches, and you can stay at a minor release and still get security updates. For CentOS Linux, a minor release is
No. RHEL minor releases are more like source control "tags" than branches. They have stable installation images one can refer and start new deployments from, and ongoing work is branched from that tag. This has been the case since the earliest Red Hat, not even RHEL, releases since I encountered them back in 1995.
a point where updates pause for a while while the team scrambles to rebuild a large update of many packages and then those packages all updated in a big chunk _on the single CentOS branch_. So this is always been extra value that Red Hat Enterprise Linux provides that CentOS Linux did not mimic.
Nothing personal, but "nonsense". See above. The PXE images and kernels in the installation media, in particular, mattered. I used to publish quite large Red Hat based deployments, and you *never* simply ran "yum update" from the live update streams at the time of building your new images or testing environments. It's why I published tools like my reposync scripts, to generate a lockable internal mirror and avoid the streaming update dangers without investing in the very large cost of an RHN setup.
IIRC thats the reason why CentOS Linux has a kickstart directory in the repo tree.
Having a stable repository for a full reference for updating an environment or especially build and testing environments synchronously is vital. It's also been very useful for "mock", since one can turn off the update channels and use the current of specific CentOS point releases for builidng software. If you're doing that with RHEL, well, frankly I'd use a locked down internal mirror. My reposync scripts and rsync tools are published at https://github.com/nkadel/nkadel-rsync-scripts . They're pretty easily linked to a filesystem that does hardlinks and allows snapshotting to produce a "current" and a datestamped, locked down copy of the repos, much like the old "rsnapshot" tool did for rsync backups. And I was a maintainer on that tool for a while, too. _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-- Leon