<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Dec 19, 2020 at 8:51 PM Tetsuo Handa <<a href="mailto:from-centos@i-love.sakura.ne.jp">from-centos@i-love.sakura.ne.jp</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2020/12/20 9:03, Peter Georg wrote:<br>
> Hence my suggestion has been to introduce a "RHEL kernel" repository that provides the current<br>
> RHEL minor releases' kernel (and directly dependent RPMs). Whenever there is an update to the<br>
> minor release's kernel (without changing the RHEL minor release), this version will be added to<br>
> the "RHEL kernel" repository. I.e., versions 4.18.0-x.y, which are never being released for<br>
> CentOS Stream.<br>
<br>
Yes, my idea resembles your suggestion.<br>
My feeling ( <a href="https://lists.centos.org/pipermail/centos-devel/2020-December/075631.html" rel="noreferrer" target="_blank">https://lists.centos.org/pipermail/centos-devel/2020-December/075631.html</a> ) is<br>
"Why are we using different binary rpm files between RHEL and CentOS Linux? Why RH does not<br>
allow CentOS Linux users to use the same binary rpm files shipped for RHEL?" They are<br>
basically the same source code (the only difference should be de-branding).<br>
<br></blockquote><div> <br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If RH allows, as an exception, CentOS Linux users to use RHEL kernels, the time lag between<br>
RHEL and CentOS Linux will be significantly reduced. Also, community can convert the overhead<br>
of de-branding into the resource for improving quality of RHEL kernels, which would be a happy<br>
thing for both RH and community.<br>
<br></blockquote><div><br></div><div>I'm pretty sure mixing RHEL content like that would be a violation of our terms.  I don't see that changing.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Also, "third party drivers" are not limited to hardware device drivers needed for booting<br>
a system. For example, a system could be booted without a kernel module for e.g. antivirus<br>
software's on-access scanning, but some enterprise systems are not allowed to operate without<br>
e.g. on-access scanning. Therefore, some enterprise systems cannot update kernels as soon as<br>
a new RHEL minor release becomes available. And buying RHEL's EUS/ELS license only for<br>
obtaining security fixes for kernels during that period (presumably a few months) is not an<br>
option. If updated kernels for previous RHEL minor release were available to everybody,<br>
everybody will be able to operate with all "third party drivers". Since the security<br>
requirement is getting tighter and tighter, the time lag between "ready to build" and<br>
"ready to install" should not be ignored.<br>
<br>
> <br>
> Once a new RHEL minor release is available, the "RHEL kernel" repository is moved to vault (or deleted?)<br>
> and we re-start with an empty "RHEL kernel" repository. We will then add the new RHEL minor release's kernel.<br>
<br>
I hope that "RHEL kernel" for older RHEL minor releases are not deleted when a new RHEL minor<br>
release becomes available.<br>
<br></blockquote><div><br></div><div>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?</div><div><br></div><div>       -Mike</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
_______________________________________________<br>
CentOS-devel mailing list<br>
<a href="mailto:CentOS-devel@centos.org" target="_blank">CentOS-devel@centos.org</a><br>
<a href="https://lists.centos.org/mailman/listinfo/centos-devel" rel="noreferrer" target="_blank">https://lists.centos.org/mailman/listinfo/centos-devel</a><br>
<br>
</blockquote></div></div>