[CentOS-devel] [EXT] Balancing the needs around the CentOS platform

Sun Dec 20 02:51:34 UTC 2020
Tetsuo Handa <from-centos at i-love.sakura.ne.jp>

On 2020/12/20 9:03, Peter Georg wrote:
> Hence my suggestion has been to introduce a "RHEL kernel" repository that provides the current
> RHEL minor releases' kernel (and directly dependent RPMs). Whenever there is an update to the
> minor release's kernel (without changing the RHEL minor release), this version will be added to
> the "RHEL kernel" repository. I.e., versions 4.18.0-x.y, which are never being released for
> CentOS Stream.

Yes, my idea resembles your suggestion.
My feeling ( https://lists.centos.org/pipermail/centos-devel/2020-December/075631.html ) is
"Why are we using different binary rpm files between RHEL and CentOS Linux? Why RH does not
allow CentOS Linux users to use the same binary rpm files shipped for RHEL?" They are
basically the same source code (the only difference should be de-branding).

If RH allows, as an exception, CentOS Linux users to use RHEL kernels, the time lag between
RHEL and CentOS Linux will be significantly reduced. Also, community can convert the overhead
of de-branding into the resource for improving quality of RHEL kernels, which would be a happy
thing for both RH and community.

Also, "third party drivers" are not limited to hardware device drivers needed for booting
a system. For example, a system could be booted without a kernel module for e.g. antivirus
software's on-access scanning, but some enterprise systems are not allowed to operate without
e.g. on-access scanning. Therefore, some enterprise systems cannot update kernels as soon as
a new RHEL minor release becomes available. And buying RHEL's EUS/ELS license only for
obtaining security fixes for kernels during that period (presumably a few months) is not an
option. If updated kernels for previous RHEL minor release were available to everybody,
everybody will be able to operate with all "third party drivers". Since the security
requirement is getting tighter and tighter, the time lag between "ready to build" and
"ready to install" should not be ignored.

> 
> Once a new RHEL minor release is available, the "RHEL kernel" repository is moved to vault (or deleted?)
> and we re-start with an empty "RHEL kernel" repository. We will then add the new RHEL minor release's kernel.

I hope that "RHEL kernel" for older RHEL minor releases are not deleted when a new RHEL minor
release becomes available.