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