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.