<div dir="ltr">> A project build is `semantically equivalent` if its build results can be either recreated exactly (a bit for bit [reproducible build](<a href="https://en.wikipedia.org/wiki/Reproducible_builds)" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Reproducible_builds)</a>), or if the differences between the release package and a rebuilt package are not expected to produce functional differences in normal cases.<br><div><br></div><div>This is why I was attempting to bring things back to desired characteristics. Intrinsic in what I suggested, talking about equivalent outputs, is that you have a definition of equivalence that is sufficiently precise that any two independent parties given the definition of equivalence and a pair of outputs will always produce the same answer as to whether the outputs are equivalent. I don't think that "the differences between the release package and a rebuilt package are not expected to produce functional differences in normal cases" meets that basic criteria. I could easily imagine two independent parties having differing opinions wrt whether two outputs are equivalent under that definition.</div><div><br></div><div>Say I have an executable with a typo in its 'usage'. I fix the typo in the 'usage' and decide to assert that the executable is semantically equivalent to the previous executable. From my point of view, its not functionally different, because I don't consider 'usage' to be functional. Someone else may be *parsing* the usage, and does consider that to be a 'functional' difference.</div><div><br></div><div>It's incredibly easy to convince yourself that your differences between two executables aren't "not expected to produce functional differences in normal cases". You have "expected" "functional difference" and "normal cases" to work with as blank spaces into which almost any definition can be pushed.</div><div><br></div><div>Please don't get me wrong, the OSSGadget folks may be doing *really* good work. My complaint is that the definition of "Semantically Reproducible" is effectively unusable as written above. Can it be tightened ups to something that at the very least meets the characteristics:</div><div><br></div><div>- Two independent parties given the definition of equivalence and a pair of outputs will always produce the same answer as to whether the outputs are equivalent.</div><div><br></div><div>Ed </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 2, 2023 at 9:46 AM David A. Wheeler <<a href="mailto:dwheeler@dwheeler.com">dwheeler@dwheeler.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On May 31, 2023, at 10:36 AM, Ed Warnicke <<a href="mailto:hagbard@gmail.com" target="_blank">hagbard@gmail.com</a>> wrote:<br>
> <br>
> I tend to think about reproducible builds in this generalizable way:<br>
> <br>
> A build is reproducible if equivalent inputs (source, build tools, build tool invocation, etc) to the build result in equivalent outputs.<br>
<br>
Fair enough. The immediate issue is to reduce confusion.<br>
<br>
The OSSGadget developers have decided to switch to the term "semantic equivalency"<br>
and "semantically equivalent":<br>
> A project build is `semantically equivalent` if its build results can be either recreated exactly (a bit for bit [reproducible build](<a href="https://en.wikipedia.org/wiki/Reproducible_builds)" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Reproducible_builds)</a>), or if the differences between the release package and a rebuilt package are not expected to produce functional differences in normal cases.<br>
<br>
Links:<br>
<a href="https://github.com/microsoft/OSSGadget/issues/426" rel="noreferrer" target="_blank">https://github.com/microsoft/OSSGadget/issues/426</a><br>
<a href="https://github.com/microsoft/OSSGadget/pull/429" rel="noreferrer" target="_blank">https://github.com/microsoft/OSSGadget/pull/429</a><br>
<br>
Their oss-reproducible tool, part of OSSGadget, uses a variety of steps to determine if a build is semantically equivalent.<br>
<br>
--- David A. Wheeler<br>
<br>
</blockquote></div>