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

[Russ Allbery]

Niko Tyni <ntyni at debian.org> writes:
> On Wed, May 20, 2015 at 10:34:20PM +0200, Niels Thykier wrote:
>> On 2015-04-19 14:35, gregor herrmann wrote:
>>> On Sun, 19 Apr 2015 14:03:44 +0200, Axel Beckert wrote:

>>>> Jelmer Vernooij wrote:

>>>>> +# Set man page timestamp to last package change time.
>>>>> +BUILD_DATE = $(shell dpkg-parsechangelog -S Date)
>>>>> +POD_MAN_DATE = $(shell date -u +"%Y-%m-%d" --date="$(BUILD_DATE)")
>>>>> +export POD_MAN_DATE

>>>> But isn't this something which should be done doing once and properly
>>>> in the build system (e.g. in dh_auto_build), like setting all the file
>>>> time stamps to that date?

>> It is not entirely clear to me what you are asking for.  Is this change
>> only supposed to go into a Perl specific build system, in all build
>> systems supported by dh_auto_build or ...?

> That's a good question. I suppose it should go in all the build systems,
> although most of the benefit is certainly for Perl module packages.

> The context is that Pod::Man sets the date header based on the mtime of
> the file, but if the file is patched by the Debian packaging, the mtime
> will be set to the extraction time, breaking reproducibility.  (See
> #759404 for some related discussion.)  The mtime will also be
> unreproducible if the file is generated during the build.

Disabling the date in the generated man page is definitely the easiest
fix.

I personally like the idea of instead setting the date to the last
modified time of the Debian package.  Actually, ideally, I wish that dpkg
itself would set the timestamp of all files modified by patches to match
the last modification date of the package, which would achieve the same
thing but at what feels like the correct level.

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.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>