On Mon, Dec 28, 2020 at 7:30 AM redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, December 28, 2020 6:16 AM, Alexander Bokovoy abokovoy@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.
At thousands of patches, it's quite slow. It's slightly faster when using the "%autopatch -S git_am" mode, but it's still very slow. The kernel package is likely to never use the standard Dist-Git model as all other packages (rightfully) do, and will use the "source-git" model in which you have a full Git tree with the packaging files and you can walk through Git commits like a developer would. I am hoping that will become available with RHEL/CentOS Stream 9 with the CKI/ARK stuff.