Irregular status update about reproducible Debian live ISO images

[Simon Josefsson]

John Gilmore <gnu at toad.com> writes:

> During development, the code would be built by some earlier release's
> tools, built piecemeal, etc, like current build processes do.  Anytime
> before release, the developers can test whether a draft source release
> builds into a binary release that itself can build the sources into the
> same binary release.  And fix any discrepancies, ideally long before
> release.
>
> This is similar to what GCC does to test itself, or what Cygnus did to
> test the whole toolchain for cross-compiling.  But applied to the
> entire OS release.

Yay! That is what I call an idempotent rebuild:

https://blog.josefsson.org/2024/07/10/towards-idempotent-rebuilds/

"Addendum about terminology: With “idempotent rebuild” I am talking
about a rebuild of the entire operating system, applied to
itself. Compare how you build the latest version of the GNU C Compiler:
it first builds itself using whatever system compiler is available
(often an earlier version of gcc) which we call step 1. Then step 2 is
to build a copy of itself using the compiler built in step 1. The final
step 3 is to build another copy of itself using the compiler from step
2. Debian, Ubuntu etc are at step 1 in this process right now. The
output of step 2 and step 3 ought to be bit-by-bit identical, or
something is wrong. The comparison between step 2 and 3 is what I refer
to with an idempotent rebuild. Of course, most packages aren’t a
compiler that can compile itself. However entire operating systems such
as Trisquel, PureOS, Ubuntu or Debian are (hopefully) a self-contained
system that ought to be able to rebuild itself to an identical copy. Or
something is amiss. The reproducible build and bootstrappable build
projects are about improve the quality of step 1. The property I am
interested is the identical rebuild and comparison in step 2 and 3. I
feel the word “idempotent” describes the property I’m interested in
well, but I realize there may be better ways to describe this. Ideas
welcome!"

I think all of these are different concepts:

- bootstrappable build

- reproducible build

- idempotent build

Bootstrappable doesn't imply reproducibility.

Reproducibility doesn't imply bootstrappability.

I think idempotent build implies reproducible build, but not necessarily
the reverse.

An idempotent build is an optimization: instead of the user having to do
bootstrappable+reproducible build for a new release of some OS, the user
could trust that someone else did that for them, and merely do an
idempotent rebuild of the OS they got to see if it is able to rebuild
itself identically.  This ought to cost less CPU cycles than performing
the entire bootstrappable+reproducible build chain themselves.

I assume that "building from source" means building from the preferred
form to make modifications to.  Not from binary packages.  I could agree
that reproducibility from some binary inputs is a nice property too
(better than not being able to reproduce the output), but it shouldn't
be confused with building from the preferred form of modifications.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1251 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20250328/3f449ced/attachment.sig>