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

On Mon, Dec 21, 2020 at 2:50 PM Stephen John Smoogen <smooge at gmail.com> wrote:
> On Mon, 21 Dec 2020 at 14:31, Mark Mielke <mark.mielke at gmail.com> wrote:
>> 4. It's still not perfect, however, in almost every way there is
>> currently a 1:1 relationship between the exact .spec file and patch
>> set being used to build CentOS releases, in parallel (or a short time
>> later) to RHEL minor release.
> A spec file is the tiniest part of making something match. Build order, hardware, etc have a larger effect.

I think your definition of match is overly pedantic, and I love it. :-)

When it comes to behaviour exhibited by the program - my own
experience is that source bundle and the patch set primary defines the
visible and user-impacting behaviours. When an issue is raised on
bugzilla.redhat.com - I know that there are some issues that have been
addressed through package re-building, or changing the order of the
build (and yes, Modularity makes this much harder), but the vast
majority of issues by quantity relate to problems in the software,
that are only addressed through source changes, that make it into
builds. The definition of which source bundle is used, and which
patches are applied on top, is the .spec file. Basically every
software fix on bugzilla.redhat.com turns into a .spec file change.
So, I do believe that .spec file is the biggest part of making things
match from a visible and user-impacting behaviouors perspective.

However, .spec file alone is not sufficient. As you say, the build
context matters as well, and this is the next level of reproducibility
that has been difficult to achieve (although, I believe it comes
"close enough" that most people cannot tell the difference even if
they were looking for one). If the .spec file were to embed the "build
requirements" not just as package dependencies, but also things like
Modularity configuration, and build baseline, this would improve
things. But, today - everything is sort of built on latest, and the
only time something is done to fix this, is when a problem is found.
CentOS 8 Stream accepts this, and makes it official. Dropping CentOS
8, means dropping any attempt to continue to solve this.

>> 5. CentOS 8 Stream is a departure from the above. What is built in
>> CentOS 8 Stream is *not* intended to be "bug-for-bug" compatible, but
> CentOS-8 has not been bug-for-bug compatible in the first place. We would still be working the initial release if we were trying that.  So please let us rephrase this
> 5. CentOS 8 Stream is not intended to have the goal of being "bug-for-bug" compatible. It is recognizing this is not possible and has not been possible since probably EL5. At any given time it is not necessarily aligned with RHEL X.Y or RHEL X.Y+1 but may be something in between or beyond depending on when the release cycle is happening.
> [That is the best over-simplification I can come up with this for.]

With the understanding that we are talking about "perfect
reproduction" and not "reproduction that would pass most inspections",
I would agree. :-)

-- 
Mark Mielke <mark.mielke at gmail.com>