From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sun, 20 Dec 2015 12:48:17 +0000
> Cc: emacs-dev= el@gnu.org
>
> Paul Eggert <eggert@cs.ucla.edu> schrieb am Mo., 7. Dez. 2015 um 20:14 Uhr:
>
>=C2=A0 =C2=A0 =C2=A0On 12/07/2015 11:00 AM, Philipp Stephani wrote:
>=C2=A0 =C2=A0 =C2=A0> this would be a rather big change.
>
>=C2=A0 =C2=A0 =C2=A0I suppose that depends on what one means by "b= ig". To me it feels like a
>=C2=A0 =C2=A0 =C2=A0fairly small improvement. We've already made so= me progress along these
>=C2=A0 =C2=A0 =C2=A0lines in emacs-25 by removing emacs-build-system fr= om the result of the
>=C2=A0 =C2=A0 =C2=A0emacs-version function; we just need to make more i= mprovements like that.
>
>=C2=A0 =C2=A0 =C2=A0It should be in 'master', though, not in = 39;emacs-25', as it's not fixing
>=C2=A0 =C2=A0 =C2=A0a 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.=C2=A0 I regret I d= idn'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.=C2=A0 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.=C2=A0 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.=C2=A0 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).=C2=A0 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.=C2=A0 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.=C2=A0 Where is all this
going?
I'm sorry, but I cannot agree to this slippery slope, just so we could<= br> support a single specialized use case.=C2=A0 Let's support that use cas= e by
providing some build-time option, either a configure-time option or a
Makefile option, or an environment variable, or something else.=C2=A0 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.