On Sat, Dec 19, 2020 at 8:51 PM Tetsuo Handa < from-centos@i-love.sakura.ne.jp> wrote:
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).
FWIW, we did actually discuss doing this. It boiled down to business reasons, and in particular the security of our supply chain (recent news only emphasizes this). The idea of using a single build is popular among some on our engineering team though. I'm sure it will be proposed again as things settle down, we can re-evaluate then.
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.
I'm pretty sure mixing RHEL content like that would be a violation of our terms. I don't see that changing.
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.
I don't think we have a particular retention policy for stream though even if we did, a simple local mirror would solve your problem, right?
-Mike
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel