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

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.html>