[PATCH] Remove SH_USE_BSD_ECHO autoconf test.

[PATCH] Remove SH_USE_BSD_ECHO autoconf test.

[Daniel Shahaf]

It is unused; doesn't make sense in "build on one box, install on many"
context; and its presence causes the downstream packages that install
config.h to be non-reproducible.
---
 configure.ac | 15 ---------------
 1 file changed, 15 deletions(-)

diff --git a/configure.ac b/configure.ac
index 920c2fc..dda52bc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2309,21 +2309,6 @@ AH_TEMPLATE([HAVE_FIFOS],
 if test x$zsh_cv_sys_fifo = xyes; then
   AC_DEFINE(HAVE_FIFOS)
 fi
-dnl ---------------------
-dnl echo style of /bin/sh
-dnl ---------------------
-AC_CACHE_CHECK(if echo in /bin/sh interprets escape sequences,
-zsh_cv_prog_sh_echo_escape,
-[if test "`/bin/sh -c \"echo '\\n'\"`" = "\\n"; then
-  zsh_cv_prog_sh_echo_escape=no
-else
-  zsh_cv_prog_sh_echo_escape=yes
-fi])
-AH_TEMPLATE([SH_USE_BSD_ECHO],
-[Define to 1 if /bin/sh does not interpret \ escape sequences.])
-if test x$zsh_cv_prog_sh_echo_escape = xno; then
-  AC_DEFINE(SH_USE_BSD_ECHO)
-fi
 
 dnl -----------
 dnl test for whether link() works

Re: [PATCH] Remove SH_USE_BSD_ECHO autoconf test.

[Bart Schaefer]

On Dec 24,  5:43pm, Daniel Shahaf wrote:
}
} It is unused

Wow.

Sometime back before 1996:

|+ #ifdef SH_USE_BSD_ECHO
|      {"bsdecho", 		0,    0,    OPT_EMULATE|OPT_SH},
|+ #else
|+     {"bsdecho", 		0,    0,    0},
|+ #endif

There is no version-controlled copy of zsh old enough to still have
this code, and the earliest reference to it in the list archive is
in reply to a message that is too old to be in the archive.

The intention seems to have been to have the default behavior of
zsh's echo builtin match the default behavior of the echo command
on the same platform.

In spite of the conditional above having been removed from (what was
at that time) globals.h, the useless configure test was revised and
kept up to date for nearly a decade, and then has been sitting there
ever since.

} its presence causes the downstream packages that install
} config.h to be non-reproducible.

I don't know what that means, but it doesn't really matter ...

Re: [PATCH] Remove SH_USE_BSD_ECHO autoconf test.

[Axel Beckert]

Hi Bart,

On Sat, Dec 24, 2016 at 01:52:31PM -0800, Bart Schaefer wrote:
> } its presence causes the downstream packages that install
> } config.h to be non-reproducible.
> 
> I don't know what that means,

it means that the resulting binaries or at least binary packages are
not bit-wise identical if built on two different machines, but on the
same (build) architecture and with the same build-dependencies.

> but it doesn't really matter ...

It matters a lot from a trust point of view. If you can reproduce a
bit-wise identical package from the same source code, you can be sure
that your copy of the code and the same compiler and dependencies were
used to produce that binary you're comparing your build to.

Please see https://reproducible-builds.org/ for more details and
background. You can track zsh's reproducibility in Debian at
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/zsh.html

Or short said: +1 for any patch which helps to make zsh reproducible.

(There are IIRC further issues with yodl/LaTeX which includes build
data like time stamps, etc. in files generated by it.)

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.nonhtmlmail.org/campaign.html | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://abe.noone.org/ (Web)

Re: [PATCH] Remove SH_USE_BSD_ECHO autoconf test.

[Bart Schaefer]

On Dec 25,  2:33am, Daniel Shahaf wrote:
}
} This output shows that the debian package of zsh is not reproducible
} (in the sense of https://www.reproducible-builds.org/ - bit-for-bit
} identical artifacts). because it contains config.h whose contents
} depend on what /bin/sh is at build time.

IMO this is just stupid.  config.h is not an output of the build, it's
an intermediate step which in this case is irrelevant.  It shouldn't
have been included in the checksum in the first place -- or conversely
it shouldn't have been included in the debian package.

Further the whole point of "configure" is to produce results that might
vary based on the buid environment.  Reproducibility should only apply
downstream of configuration, if it's to have any value at all.

Re: [PATCH] Remove SH_USE_BSD_ECHO autoconf test.

[Nikolay Aleksandrovich Pavlov (ZyX)]

25.12.2016, 21:07, "Bart Schaefer" <schaefer@brasslantern.com>:
> On Dec 25, 2:33am, Daniel Shahaf wrote:
> }
> } This output shows that the debian package of zsh is not reproducible
> } (in the sense of https://www.reproducible-builds.org/ - bit-for-bit
> } identical artifacts). because it contains config.h whose contents
> } depend on what /bin/sh is at build time.
>
> IMO this is just stupid. config.h is not an output of the build, it's
> an intermediate step which in this case is irrelevant. It shouldn't
> have been included in the checksum in the first place -- or conversely
> it shouldn't have been included in the debian package.
>
> Further the whole point of "configure" is to produce results that might
> vary based on the buid environment. Reproducibility should only apply
> downstream of configuration, if it's to have any value at all.

It is not. config.h is output of the build because it is required to build third-party modules because you can’t #include zsh header files without having config.h saved somewhere.

Basically it appeared in the package some time after zpython module was rejected from inclusion in core.

Re: [PATCH] Remove SH_USE_BSD_ECHO autoconf test.

[Daniel Shahaf]

Bart Schaefer wrote on Sun, Dec 25, 2016 at 10:06:19 -0800:
> Further the whole point of "configure" is to produce results that might
> vary based on the buid environment.  Reproducibility should only apply
> downstream of configuration, if it's to have any value at all.

Sure; reproducibility means that given the same inputs, the (bitwise
identical) same output is produced.  Flags to configure are obviously
part of the input.  What was being tested here is that the behaviour of
«/bin/sh -c 'echo "\n"'» is _not_ part of the input, i.e., that the same
output is produced even for build environments having different
/bin/sh's.