[adding reproducible-bui...@lists.alioth.debian.org to CC]
Johannes 'josch' Schauer wrote:
> This is problem for reproducible installations because the exact same
> package set, consisting of systemd and systemd-timesyncd can result in a
> different system after installation.
I remember working on related issues in Tails which releases
bit-for-bit reproducible ISO images.
In the end, we went with a horrible post-build script that swapped
group IDs that were assigned non-deterministically due to the
arbitrary execution order of the postinst scripts.
I mention this here to encourage us exploring an archive-wide solution
rather than fixing every time it comes up.
This is a particularly good candidate for a general solution as, in my
hard-won experience:
a) The non-determinism can happen infrequently and thus does not appear
even in extensive testing.
b) There was no way to flush out the problem in CI (compare using
disorderfs to reverse your filesystem ordering to
deterministically flush out non-deterministic behaviour or similar
tricks.)
c) Each test build run can take a significant amount of time.
d) The packages could be entirely unrelated. As in, it could have
been between entirely different packages that could not have been
fixed by adding a relationship.
(Tails also has unrelated reasons for having persistent GIDs across
builds with different inputs. I would immediately concede that
these are out of scope for Debian itself to resolve.)
I'm not sure exactly where this change could be made (dpkg? apt?) as I
lack a confident understanding of the exact roles of those two tools,
but I am assuming that one of these is *eventually* deciding whether to
run the postinst for systemd or systemd-timesyncd first.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org 🍥 chris-lamb.co.uk
`-
