Hi Daniel,
Daniel Shahaf wrote:
> Axel Beckert wrote on Sun, Dec 25, 2016 at 17:17:36 +0100:
> > Both issues are about zsh-dev not being reproducibly if once /bin/sh
> > is dash and once bash.
> >
> > One issue (upstream) is about fixing configure.ac, Makefile.am so that
> > this no more happens.
> >
> > The other issue (this Debian bug report) is about whether we want to
> > continue to differ from upstream wrt. the inclusion of config.h in the
> > zsh-dev package.
>
> Yes. This issue is not just about config.h, actually; it's about how
> the package installs _all_ *.h and *.epro files, without making
> a distinction between what's an interface between core and modules, and
> what's an intra-core interface. ("intraface"?)
Ah, ok.
> For functions, the distinction is easy: only functions that are tagged
> "mod_export" should be used by modules, however, zsh-dev installs
> prototypes of other functions as well, such as findpwd(). That function
> is defined with external linkage (= without the "static" keyword), but
> without the "mod_export" annotation, meaning that modules that #include
> /usr/include/zsh/utils.epro will be able to call findpwd(), even though
> upstream does not consider that function a public/stable API.
>
> For preprocessor macros and type definitions there is no equivalent of
> the "mod_export" explicit scoping tag, however, we have no reason to
> believe that every single #define and typedef shared between different
> *.c files of zsh core, is blessed for use by modules. We shouldn't
> install #define's and type definitions that upstream has not
> specifically blessed as an interface between modules and core.
So let me recap:
* Upstream installs only header files which are marked mod_export.
This does not include e.g. config.h.
* config.h is needed in some cases anyways, c.f. #776964.
So after that, it looks to me (again) like an upstream issue to me:
Upstream does not install all files necessary to compile external
modules. http://www.zsh.org/mla/workers/2016/msg02720.html seems to
summarize this issue rather well.
> > Obviously the following actions would resolve this Debian bug report
> > (#849288):
> >
> > * Upstream changes its code to install config.h as well.
> > * We stop shipping config.h. That would reopen #776964.
>
> To be clear, these options are mutually exclusive, not cumulative.
Yes, that list was meant mutually exclusive.
> > But what I currently plan to do is to use the patch from
> > http://www.zsh.org/mla/workers/2016/msg02716.html and hence make
> > zsh-dev reproducible again without having decided on the config.h
> > inclusion discusssion.
>
> +1, and thanks. I'll push it upstream soon.
Planned to import that, but got confused, as patch thinks that patch
is already applied:
→ GET http://www.zsh.org/mla/workers/2016/msg02716.html | tail -53 | head -27
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
→ GET http://www.zsh.org/mla/workers/2016/msg02716.html | tail -53 | head -27 |
patch -p1
patching file configure.ac
Reversed (or previously applied) patch detected! Assume -R? [n] ^C
→ egrep -n 'HAVE_FIFOS|SH_USE_BSD_ECHO|test for whether link' configure.ac
2307:AH_TEMPLATE([HAVE_FIFOS],
2310: AC_DEFINE(HAVE_FIFOS)
2322:AH_TEMPLATE([SH_USE_BSD_ECHO],
2325: AC_DEFINE(SH_USE_BSD_ECHO)
2329:dnl test for whether link() works
I don't get why patch thinks that the patch is already applied. It's
clearly not. Anyone an idea here?
> > Would that action close this issue, too, or not? Because if zsh-dev
> > becomes reproducible, this is mere a "we differ from upstream" issue,
> > nothing more and not really a bug anymore, at most a wishlist item.
>
> Making zsh-dev reproducible would not close this issue.
I agree. And there's currently no bug report for that reproducibility
issue. (Not sure if opening one helps, though.)
> I've retitled this bug to clarify its scope.
Thanks!
Regards, Axel
--
,''`. | Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
