Collaborative Working Sessions - RB Definition
Definition of Reproducible Builds (day 3 morning session)
A build is reproducible if given the same:
- source code
- build environment
- build instructions
any party can generate bit-by-bit identical copies of all specified artifacts.
main page
RB are a set of software dev practices that create an independently verifiable path from source to binary code.
- a mathemathicaly definition that
- RB process should be repro
- human verifiable inputs, process, and bit-by-bit identical output
- “Why?” should be in definition
- source code doesn’t abstract world cases (binary)
- the definition doesn’t hold for everyone
WIP below is copied straight from the pad, to merge and turned in markdown
RB Definition Notes
Leading the session: Aman Taking Notes: Martin
Martin will try to do a pass over these notes after the summits and email the participants to get agreement on the discussion summary, so that we can move the discussion forward from there towards making actual changes to the definition. z Who is the target audience of the definition?
Issues:
- binary blobs / arranging binary blobs in a reproducible manner
-
what is a build?
-
calling artifacts reproducible VS calling parts of the process reproducible
-
what is the process that you are calling reproducible?
-
making reproducibility claims about defined inspectable boxes?
- It’s unclear what a build is. We want to have a triplet: inputs, build instructions, output
- you can include the build instructions in the input
-
functions can be composable
-
inputs to outputs idea is received positively
-
input can pe reproducible, process can be reproducible, artifact can be reproduced (form a process)
-
input section, output section, builder section
-
given the same build inputs and the same build function, the output is bit-by-bit identical
-
define abstract machine-evaluatable technical definition then construct a more user-friendly and goal-oriented definition from that
-
if i have a bizarre system or impossible build I can confidently make the claim that something is reproducible
-
seperate what the reproducible builds movement wants to achieve form the technical definition of reproducibility itself
-
people might want to claim my process is reproducible even under a file system that randomizes file order
-
something is reproducible if it has been reproduced?
-
if something is reproducible, but you need a very specific environment to reproduce it, that makes the property less useful
- we want something that’s easily and readily reproducible, that provides enough information about how to reproduce it such that people are able to
- clear enough about the process and required inputs
- Practically projects should seek to make reproducing their software easy, cheap and reliable.
Takeaways
- we want to seperate the current definition into (motivation and goals) and a more formal definition of a property
- the proerty should apply a build process and not an artifact
- a simpler more mathematical definition, a more complex goal-oriented
- martin will write up some suggestion for how to define reproducibiliy based on his work
- everything that’s not explicitly stated as an input to the process should not matter
- should be defined as a pure function, more mathematical
What we don’t like about the definition
- it does not hold for everyone:
- something being reproducible for one person may not mean it being reproducible for another person
Afternoon session
- Unanimous agreement that the goal and the definition should be separate.
- We no longer want to include “human verifiable” as part of a property when something is reproducible.
-
Reproducible can be from inputs that are not reproducible or somehow human verifiable, they are two different goals and different properties of build processes.
- We are now unaligned whether we want this isolated definition, some want to exclude some inputs from being allowed, like references to remote artifacts that have to be fetched, and that the process should not be allowed to use the network.
-
Also there is some discussion whether maybe something is supposed to have levels.
- Unclear whether we want to positively list all the things the build is dependent upon, or list all the things the build is independent upon.
-
Unclear outcome…
- We agree with parameterized definitions, unclear whether confirm or deny defaults.
- One thought is that perhaps we don’t want inputs that can be changed externally.
How to move on:
- We want more than one word of reproducibility
- More different terms, or at least split up the current definition in smaller parts
- Just put it on the notes