Re: [PATCH PING] Honor 'SOURCE_DATE_EPOCH' when generating autoloads.

[Eli Zaretskii <eliz@gnu.org>]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sun, 20 Dec 2015 12:48:17 +0000
> Cc: emacs-devel@gnu.org
> 
> Paul Eggert <eggert@cs.ucla.edu> schrieb am Mo., 7. Dez. 2015 um 20:14 Uhr:
> 
>     On 12/07/2015 11:00 AM, Philipp Stephani wrote:
>     > this would be a rather big change.
>     
>     I suppose that depends on what one means by "big". To me it feels like a
>     fairly small improvement. We've already made some progress along these
>     lines in emacs-25 by removing emacs-build-system from the result of the
>     emacs-version function; we just need to make more improvements like that.
>     
>     It should be in 'master', though, not in 'emacs-25', as it's not fixing
>     a bug.
> 
> OK, here's a first patch that replaces system-name with a constant during
> dumping. That eliminates one source of nondeterminism.

I'm sorry, but I don't like where this is going.  I regret I didn't
speak up earlier, but better late than never.

In a nutshell, I object to losing valuable information for the benefit
of a single specialized use case.  I have nothing against supporting
reproducible builds as long as this removes information and data that
is not important to us humans when developing or debugging Emacs.  For
example, changes in loaddefs files that remove non-deterministic
information from there or replace it with deterministic information
are fine with me.

But here we are losing information about the build system that I found
useful more than once in the past when tracking bugs.  We have already
removed the build system name from the bug report produced by
report-emacs-bug (I'm going to add it back, btw, unless someone
provides a _very_ good reason for its removal).  Earlier, we removed
the last keystrokes, because someone was worried about their privacy,
but couldn't be bothered to delete the sensitive parts from the bug
report.  And your comments indicate that you intend to remove the
build time as well, so it will be impossible to say whether a given
binary was built before or after some change.  Where is all this
going?

I'm sorry, but I cannot agree to this slippery slope, just so we could
support a single specialized use case.  Let's support that use case by
providing some build-time option, either a configure-time option or a
Makefile option, or an environment variable, or something else.  If
someone presents a convincing case, I might even agree to have the
release tarball build by default with that information removed
(although I found it useful in the past when reading bug reports).
But doing this in the development version is simply a non-starter.
When debugging some problem that happened elsewhere, we quite often
need every bit of information that could potentially help us, so
removing it is out of the question.

I appreciate your efforts in providing the patch, but we will have to
find another way of supporting reproducible builds.

Thanks.