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
