misleading timestamps in binnmus

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

I have just had my backups fail due to the following chain of events:

 * I had python2.7-stdlib:amd64 2.7.12-3 installed
 * I did a backup
 * I upgraded to python2.7-stdlib:amd64 2.7.12-3+b1 was built
 * I did another backup, during which:
 * Many files were not copied to the backup volume because
   their mtimes had not changed
 * However, the contents of these files had changed because of the
   rebuild
 * My backup system is clever enough to spot that there is a problem

I see the python2.7 source package does this:

 LAST_CHANGE := $(shell dpkg-parsechangelog -S Date)
 export BUILD_DATE := $(shell LC_ALL=C date -u +'%b %e %Y' -d '$(LAST_CHANGE)')
 export BUILD_TIME := $(shell LC_ALL=C date -u +'%H:%M:%S' -d '$(LAST_CHANGE)')

Is this a recommended recipe ?  AIUI a buildd doing a binnmu will not
modify the debian/changelog file.

The result is that the file timestamps will be lies after a binnmu.  I
think this is quite undesirable.  Less careful backup programs than
mine wouldn't notice.  The results would then be a corrupted backup,
which would break when restored.  There are probably other bad
consequences.

Can we come up with a better recipe ?  For example perhaps

 DEBIAN_LAST_CHANGE ?= $(shell dpkg-parsechangelog -S Date)

which would make it possible for a buildd to override the value.

Thanks for your attention.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.