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 ste...@pyro.eu.org _______________________________________________ Reproducible-builds mailing list Reproducibleemail@example.com http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds