Bug#782879: [Reproducible-builds] Bug#782878: [debhelper-devel] Bug#782879 + Bug#782878: lib{test-log4perl, scalar-defer}-perl: please make the build reproducible

[Steven Chamberlain]

Hi,

Russ Allbery wrote:
> My feeling is that the date in the man page serves a useful purpose for
> the end user by communicating some idea of the "staleness" of the
> documentation and the recentness of the last release of the software.
> While this isn't a huge deal, it does feel somewhat less than ideal to
> lose that data.  Replacing it with the last modification date of the
> Debian package isn't perfect, but it's fairly reasonable.

I'm suffering this issue in a different context, which is a binary
package that ships a tarball of the kfreebsd (kernel) source.  Some of
those files are patched by dpkg-source.

>From #759404 I can see why dpkg-source can't really help with this.

It would be a shame to lose / reset all the timestamps, because:
  * it's useful to know how old a file is, if Debian didn't patch it,
  * installing the package, extracting files with newer timestamps,
    could mean some systems for backup or deduplication must treat the
    files as though they are new/changed,
  * in a new package revision, if the files in a particular .deb didn't
    change, it would be nice if the data.tar.xz didn't change;  this
    would be helpful to future work on .deb deltas or deduplication.

I suggest to only 'clamp' timestamps to the latest entry in
debian/changelog.  I think only timestamps newer than this are likely
an issue for reproducibility.  Older timestamps are potentially still
useful.

Regards,
-- 
Steven Chamberlain
steven at pyro.eu.org