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

On ma, 28 joulu 2020, redbaronbrowser wrote:
>‐‐‐‐‐‐‐ 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.

35 patches, as applied in  https://kojipkgs.fedoraproject.org//packages/kernel/5.10.2/200.fc33/data/logs/x86_64/build.log

$ curl -s https://kojipkgs.fedoraproject.org//packages/kernel/5.10.2/200.fc33/data/logs/x86_64/build.log | grep Applying: | wc -l
35

I don't think that is representative. 

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

That would be a major issue with reproducible builds and with security
of the build environment.

Anyway, it is just my thought on what could be affecting an RPM build
with 'too many' patches.

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland