
<!DOCTYPE html><html><head><title></title></head><body><div>On Fri, May 16, 2025, at 00:13, David A. Wheeler via rb-general wrote:</div><blockquote type="cite" id="qt" style=""><div>> On May 11, 2025, at 5:14 PM, Vagrant Cascadian <<a href="mailto:vagrant@reproducible-builds.org">vagrant@reproducible-builds.org</a>> wrote:</div><div>> The definition as it stands does have some oddness when considering</div><div>> things like system images, container images, etc. and I feel very mixed</div><div>> about letting go of the focus on source code, even though I do think</div><div>> there is space to call some of these usefully reproducible, I very much</div><div>> worry about dilluting the Reproducible Builds definition too much to</div><div>> accomodate them; I have the strong suspicion there will be unintended</div><div>> consequences.</div><div><br></div><div>Do others also have that concern?</div></blockquote><div><br></div><div>I do think it's valuable to have precise wording to distinguish between those scenario's, yes.</div><div><br></div><blockquote type="cite" id="qt" style=""><div>If so, there's a simple solution: Use the two original definitions</div><div>of reproducible builds (combined so they don't conflict) that *require*</div><div>source code, and provide a new term for the case where you don't necessary</div><div>have source code (for the Debian ISO case). I suggest calling these</div><div>"regeneratable builds" and make it clear that these two ideas are</div><div>very similar but not *exactly* the same.</div></blockquote><div><br></div><div>I would like to propose the concept of a "reproducible build process". A reproducible build process would be a process that, given the same inputs and build environment, can produce the bit-by-bit same output - without the requirement that the inputs are in source form. A "reproducible build process" only leads to an actual "reproducible build" if its inputs are either source, or reproducible builds themselves.</div><div><br></div><div>This way we can still refer to (and celebrate) the meaningful achievement of making the ISO build process reproducible, while acknowledging that for the ISO itself to be actually-fully reproducible, perhaps some of the input .deb's still need to be made reproducible. When that's achieved, it may be 'reproducible except for a few well-known binary blobs in the inputs' (which is notably distinct from 'reproducible except for a few timestamps in the output', as it's stable).</div><div><br></div><div>This does make it more important to distinguish which things are 'build inputs' and which things are 'part of the build environment'. Tools like compilers are clearly 'part of the build environment', and libraries that get linked into the resulting artifact are clearly(?) 'build inputs'. However, in cases where you for example "build against an SDK or library" without actually including the SDK/library in the resulting artifact (e.g. dynamically linking), my impression is that we would consider this build 'reproducible' even when the that SDK/library itself isn't. So a "build input" is something that gets converted into something that is found in the output, while the "build environment" is anything that is needed to make that conversion happen, but doesn't 'itself' translate to something in the output. That does not feel entirely satisfying yet but seems sensible?</div><div><br></div><div>This also seems to nicely compose with "bootstrappable builds": for a reproducible build to also be bootstrappable, not only the build inputs, but also the build environment must be (transitively) in source form.</div><div><br></div><div><br></div><div>Kind regards,</div><div><br></div><div id="sig124436424"><div class="signature">-- </div><div class="signature">Arnout Engelen</div><div class="signature">Engelen Open Source</div><div class="signature"><a href="https://engelen.eu">https://engelen.eu</a></div></div><div><br></div></body></html>