Allow to override build date with SOURCE_DATE_EPOCH

[bmwiedemann]

Allow to override build date with SOURCE_DATE_EPOCH
in order to make builds reproducible.
See https://reproducible-builds.org/ for why this is good
and https://reproducible-builds.org/specs/source-date-epoch/
for the definition of this variable.

Without this patch, /var/lib/mhvtl/CLN101L4/meta and other meta files
differed for every build.

 00000100  54 4c 43 4c 4e 31 30 31  4c 34 5f 31 35 35 34 32  |TLCLN101L4_15542|
-00000110  30 39 32 32 36 00 00 00  00 00 00 00 00 00 00 00  |09226...........|
+00000110  30 39 33 30 32 00 00 00  00 00 00 00 00 00 00 00  |09302...........|
 00000120  00 00 00 00 03 80 00 00  00 7f 00 00 00 00 00 00  |................|
-00000130  00 00 31 35 35 34 32 30  39 32 32 36 00 00 46 46  |..1554209226..FF|
+00000130  00 00 31 35 35 34 32 30  39 33 30 32 00 00 46 46  |..1554209302..FF|
 00000140  06 08 00 00 00 00 00 00  00 00 14 00 76 74 6c 2d  |............vtl-|

Signed-off-by: Bernhard M. Wiedemann bwiedemann@suse.de

This PR was done while working on reproducible builds for openSUSE.

[markh794]

Why would you want to do this ?
When you buy 'new' tapes - you get new s/n. The s/n for the virtual media is based around the ctime the media is initially created (i.e. Using the ctime as a poor mans unique id).
The virtual media is not packaged with the RPM builds (improvement here would be to not run the make_vtl_media script during the RPM build process)

[gonzoleeman]

Mark, he supplied a link explaining why it's a "good thing". Given a set of binaries, how do you know it's "safe", i.e. not corrupted/infected? You know if the binaries match a known pattern, which requires repeated builds to supply the same pattern.

I agree with you that the non-repeatable files should be separated. I wish there was a good way to initialize the mhvtl "system" without having to do it at RPM build time, but there aren't many choices. You either do it at RPM build time, RPM install time, or the first time it's used (i.e. "just in time").

[markh794]

I've read the link and agree in principle with binaries and files included with a package. However, the virtual media is not packaged and is not visible to anybody outside the build process.
Including the patch would affect the end user attempting to create new media.
Re-creating the same barcode - should generate a new media serial number. (i.e. Emulate buying new tape and swapping the barcode).
Backup application would get very, very upset if the media with same barcode & serial number had different data on it.

[bmwiedemann]

Did you notice that the default behaviour remains as it was, and only if the SOURCE_DATE_EPOCH environment variable is set during our package build, its value is used instead of the build date.

Or does this still affect users?

[markh794]

Umm.. No. Thanks for the additional info. I'm merging it now.