[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#1004557: man-db: please make index.db installations reproducible

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

Reply to: