On Sat, Dec 19, 2020 at 8:51 PM Tetsuo Handa < from-centos at 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 at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20201219/acca4500/attachment-0005.html>