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
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
