Quoting Johannes Schauer Marin Rodrigues (2022-01-31 22:23:53) > I talked with Guillem about the possibility of changing update-alternatives > to produce reproducible mtimes. I'm adding debian-dpkg@lists.debian.org to > discuss having a reproducible index.db by changing unattended-upgrades. > > Reading the commit you quote above it seems that using the symlink's mtime is > on purpose? I think the problem would not exist if the mtime of the link target > would be used. But there is probably a reason why this is not done already? > > Guillem also brought up that using SOURCE_DATE_EPOCH is wrong in this context > because this is about runtime behaviour. I disagree with that assessment. The > idea would be to check whether SOURCE_DATE_EPOCH is set in unattended-upgrades > and only if it is, then change its behaviour. That means that the current > behaviour of unattended-upgrades would be unchanged without SOURCE_DATE_EPOCH > set. Only when building something that needs to be reproducible like a chroot > tarball or system image, SOURCE_DATE_EPOCH would be set. Since building a > chroot tarball or system images is essentially compiling a final artifact from > some other input I think this is completely in line with the idea that > SOURCE_DATE_EPOCH is there to allow creating reproducible build output. In that > sense, unattended-upgrades would be in line with many other tools that respect > SOURCE_DATE_EPOCH and thus differentiate between the scenario where they are > used in the context of some build process (here: creating a chroot tarball) or > normal operation. I don't think that it makes a difference that the input to > the build process here are binary packages and not sources. During normal > package building, build dependencies also do not always provide some human > readable source that is then recompiled but also just binary material that is > then integrated into the final build output. > > Guillem was thinking about introducing a new variable in addition to > SOURCE_DATE_EPOCH to indicate that some software should produce reproducible > output in scenarios like this. This would mean that software that already > supports SOURCE_DATE_EPOCH and is called by maintainer scripts now has to be > patched to do the special casing for SOURCE_DATE_EPOCH as well as for the new > variable. I also don't think a new variable is a good idea because I think that > building a reproducible chroot tarball can be well described as some sort of > build process for which SOURCE_DATE_EPOCH makes perfect sense. > > We also thought about letting unattended-upgrades use the mtime of the symlink > target as the mtime of the symlink. But this would be a bad idea because backup > software will likely not notice a change of the symlink in case the symlink > switches to a target with a lower mtime. And of course all mentions of unattended-upgrades above should've been update-alternatives instead. Sorry for that.
Attachment:
signature.asc
Description: signature