[PATCH 2/2] Allow to override build date with SOURCE_DATE_EPOCH

[Bernhard M. Wiedemann]

On 05/11/2018 18.29, Nick Clifton wrote:
> 
> I *really* don't like this solution to the problem.  There are several
> reasons:
> 
> Â  * There is no documentation on this environment variable, so
> Â Â Â  users are not going to know that it exists.

That can be added. I did not want to go though the effort without
knowing if the change would be accepted.

> Â  * There is already a well established way of customizing the
> Â Â Â  behaviour of the linker: command line options.

When you look at the discussion in
https://lists.xenproject.org/archives/html/xen-devel/2018-10/msg01820.html
leading to
https://lists.xenproject.org/archives/html/xen-devel/2018-10/msg01850.html
you will see, that one problem with command line options is, that they
only work with new versions and break on old versions, so every caller
has to spend effort on detecting availability of options.

The other general downside for distributions like openSUSE is that such
CLI options need to be added in many places - a quasi infinite number
(if you consider all the software that is yet to be written).
OTOH an environment variable we can set once in a single place and you
are done.
https://github.com/ImageMagick/ImageMagick/pull/1270 illustrates this
concept nicely.
It does not matter as much in this case, because we do not ship that
many PE binaries.


> Â  * Possibly the most important: It is really hard to debug problems
> Â Â Â  reported by users when there are environment variables controlling
>     the behaviour of the program.  Most users will not even bother to
> Â Â Â  include the environment variables in the bug report, and even if
> Â Â Â  they do, they could be misleading if the build system involved
> Â Â Â  overrides these variables for its own purposes.

I can understand this concern.
Maybe there could be some --debug mode where it dumps all relevant
inputs (env vars, config files, CLI options, versions)

And then, the effect here is very limited in scope, so I would not
expect many reported problems.

> My suggestion would be to modify the already existing --insert-timestamp
> option, so that it can take an option argument specifying the time to be
> inserted.  That ought to work and would, in my opinion, be much better
> than using environment variables.

In terms of reproducible-builds, it would be equivalent to the current
--no-insert-timestamp, so I see little value in that.

One idea was to just check if an environment variable is set to decide
on if to include a timestamp. Saves on parsing and avoids trouble with
y2038.


Ciao
Bernhard M.