[Pkg-zsh-devel] Bug#849288: Bug#849288: Bug#849288: zsh-dev: installing config.h breaks reproducibility (followup to #776964)

[Daniel Shahaf]

Control: retitle -1 zsh-dev: installs header files containing declarations of non-"mod_export" functions (followup to #776964)

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"?)

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.

> 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.

And they refer not just to config.h but in general, to all header files
(*.h, *.epro) that are installed by zsh-dev v. by upstream.

> 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.

> 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.  This issue is
about the divergence from upstream: since zsh-dev.deb installs headers
upstream does not, users of zsh-dev could rely on interfaces that
upstream does not bless for usage by modules.  (Such as findpwd())

Apologies for not giving these details and concrete example earlier;
that might have been clearer.  I've retitled this bug to clarify its
scope.

Cheers,

Daniel