On Sun, Dec 20, 2020 at 6:34 PM Gordon Messmer <gordon.messmer at gmail.com> wrote: > > On 12/19/20 8:27 PM, Nico Kadel-Garcia wrote: > > On Sat, Dec 19, 2020 at 12:29 PM Matthew Miller <mattdm at mattdm.org> wrote: > >> 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. > > Are you saying the > > CentOS point releases do *not* match as closely as possible the > > corresponding RHEL point release? > > > No, no one is saying that. Matthew said that you can stay at a minor > release of RHEL and still get security updates. CentOS does not offer that. If I may say, I didn't see him say that. If you call Red Hat about current CVE's, the updates are in the main update channels. > In RHEL, a minor release is a branch. You can install RHEL 7.8, and > keep a host on RHEL 7.8 until the end of its life cycle. If you want > long term support for an OS with minimal changes, but continued support, > that's a thing that RHEL provides. And for CentOS, you point them to the vault archives of the old OS for installation media, and apply the updates as needed from the main channel. Does Red Hat publish new sub distributions and installation media for RHEL 7.0, 7.1, etc? The last time I needed that, they walked me though building my own PXE image as needed. > CentOS doesn't offer that. If you're using CentOS, you're always on the > "latest" branch. You either apply feature updates that come with each > point release to get security updates, or you stop applying updates > entirely and run the risks that come with not applying security or > bugfix updates. Unless you point to vault.centos.org or, if you're thoughtful, set up an internal mirror of vault. It's just like what I did with RHEL installation media to have internal point releases accessible in yum repos without paying for RHN and doing host-by-host individual tuning. Getting the point releases published as a testable, designated set of packages is critical for stability in large environments. In that way, they very much resemble a "git tag". > Mark is confusing the issue somewhat. I *think* he is trying to say > that when we say that CentOS point releases have no branches, we're > saying that there's no QA, which is absolutely not what we're saying. > We're not talking about the back end development process, we're talking > about the products that are delivered to customers. Customers can > choose what branch of the RHEL product to deploy on their systems, and > how long to use a given point release. CentOS users don't get that > level of support. Can you think of or name *any* who get updates published only for their older version of RHEL, rather than published as part of the main channels? Back in a previous role, I sometimes got beta kernel updates via a back channel, but the updates showed up quite soon in the main codeline's kernel. Way back when, sometimes my employers *sent* kernel tuning patches.