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

Steven Chamberlain

Reproducible-builds mailing list

Reply via email to