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

Mon Dec 28 12:30:14 UTC 2020
redbaronbrowser <redbaronbrowser at protonmail.com>

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, December 28, 2020 6:16 AM, Alexander Bokovoy <abokovoy at redhat.com> wrote:

> On ma, 28 joulu 2020, redbaronbrowser via CentOS-devel wrote:
>
> > But there is one "magic wand" that can help fix issues without a bug
> > report which is to empower the community with the resources that should
> > come with being the upstream provider. Right now the Stream kernel has
> > four patches which are all for debranding. The 4.18 kernel tar.xz file
> > in the SRPM is 110% the size of a vanilla tar.xz for 4.18. What is
> > that additional 10%? How many patches are there? How many are
> > security patches? How many are bug patches? How many are feature
> > patches? How many patches were added between releases? How does a
> > CentOS Stream contributor roll back individual patches?
> > If killing CentOS 8 before 2022 is part of an effort to close the
> > openness gap and to better address bugs, then let's /REALLY/ do that
> > with a kernel SRPM. It is time to make the patch information fully
> > open to assist the community in fixing bugs.
> > But if the kernel SRPM can be left in the horrific state it currently
> > is, then stop hitting us with all this empty posturing about the
> > so-called positives we get out of killing CentOS 8 early.
>
> These are good questions too. I have no experience working with RHEL
> kernel packaging myself, but looking at the changelogs, I wonder how
> many individual patches would be there. One thing I noticed in past is
> that using tens of thousands of patches in RPM spec file will amount to
> tens of thousands individual invocations of /usr/bin/patch command, each
> with its own cost. What is a cumulative overhead of that? Sadly, I was
> not able to find any performance investigations for GNU Patch. May be
> this can be done as a synthetic test using kernel changesets (5.10
> development cycle got 16K of non-merge changesets, for example).

If you run "rpmbuild -bp" against a Stream kernel SRPM and a Fedora kernel SRPM, you can then see the difference made by running patch only 4 times vs 70 times.

In my experience, the prep section of building a kernel always amounts to less than 1% of the overall build time.  There is no time savings by pre-applying the patches that justifies the lack of time savings.

If building time is a concern, then rpm-build should stop erasing the entire rpmroot directory and let make reuse object files based on source files which didn't change between releases.