I think there are at least three ways that folks interpret “reproducible builds”:
1. Deterministic build process – when I re-run a build the same steps happen regardless of environment (i.e. developer workstation vs CI/CD system). This is important for developer sanity.
2. Artefacts that can be recreated – I can reproduce an equivalent artefact at an arbitrary future point. This is useful i.e. for figuring out customer reported issues on prior versions.
3. Binary reproducible – when I re-run a build with the same inputs I get bit-for-bit identical outputs. Useful for delivery optimisation and verifying builds.
These are all good things. 1 is going to pay dividends quite quickly when engineers have fewer “it works on my machine” head scratching moments. 3 is the gold standard, but is a long hard journey.
story of repeatable to binary-reproducible builds was fascinating. Those projects continue to make improvements to this day – such as hash equivalence enhancements mentioned in https://yoctoproject.org/2021-a-year-in-review/… –
which are providing both developer experience benefits (better caching of intermediate artefacts) for their users and multiple benefits for their users’ users (verifiable builds, more optimal binary diffs for updates, etc).
Reproducible builds are a very interesting area for often under-appreciated software engineering work. I understand why not every software team is looking to achieve
I have been pointing this out for a while now! "Reproducible builds" and "rebuilding" are all overloaded terms mostly as a result of becoming buzzwords. I don't think there is a good way to "reclaim" the word and now people are talking about "verifiable builds"