idempotent rebuilds

[Simon Josefsson]

All,

I was watching [1] on rebuilding what ftp.debian.org distribute, which
is great work!  There is a question at the end about what we do if
snapshot burns, and it got me thinking again about what properties we
want from a reproducible Debian.  Let's say we reach 100% reproducible
Debian in trixie+X rebuilding packages using Built-Using dependencies
from snapshot.d.o, like the rebuilderd effort which is underway.

What would be left to improve then?

It doesn't strike me as ideal situation that when rebuilding, let's say,
the coreutils distributed for trixie+X we may need to download groff
from say trixie+X-1, or even a groff that wasn't in any stable release.
This happens if we reproduce packages using build dependencies from
Built-Using:

Shouldn't we try to reproduce the coreutils binary package in trixie+X
by rebuilding it using the version of Build-Depends that are in
trixie+X?

If there is a reproducability difference between these two approaches,
isn't that something that should be fixed?

Compare this with building gcc; it first builds a copy of gcc using the
system compiler (comparable to the rebuilderd effort) and then rebuilds
itself using the newly built gcc and comparing the results (no effort on
this underway today for Debian).

Opinions may differ, but having a state where 100% of Debian trixie+X is
reproducible only if you have access to potentially a large fraction of
packages ever published by Debian doesn't sound ideal to me.  One goal
with all this is that we can identify what source code was used to build
the software we use, and be able to audit that.  It is less work to
audit all of trixie+X source code than to audit all of trixie+X PLUS all
required build-dependencies going back to the beginning of time, which
may include no longer available packages (for legal or technical
reasons).

So what I'm suggesting is that it would be useful to have a reproducible
rebuild effort that publish diffoscope output comparing what we publish
with a new rebuild of the package using the latest build-dependency
versions.  And ultimately what should go into policy is that packages
built this way have to be reproducible.

/Simon

[1] https://toulouse2024.mini.debconf.org/talks/4-reproducible-builds-rebuilding-what-is-distributed-from-ftpdebianorg/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20241204/114157ea/attachment.sig>