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>