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

[Daniel Shahaf]

Axel Beckert wrote on Tue, Dec 27, 2016 at 18:21:43 +0100:
> Hi Daniel,
> 
> Daniel Shahaf wrote:
> > Axel Beckert wrote on Sun, Dec 25, 2016 at 17:17:36 +0100:
> 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.

Yes, the issue should be fixed upstream.  However, that does not negate
the fact that the package is wrong to install all *.h/*.epro files
indiscriminately...

In an ideal world, upstream's "make install" puts in ${prefix}/include/zsh/
header files that contain only stuff blessed for use by modules, and the
package just uses that as-is.  Upstream's makefile does not currently
behave this way.  So, I think two distinct fixes are needed:

1) Upstream's makefile needs to install whatever third-party modules
need to be able to build outside a zsh build tree.  (That means header
files containing the appropriate subset of declarations, etc., and
possibly pkg-config files and so on.)

2) In the meantime, the package shouldn't be exposing its users to
interfaces that upstream has not labeled as "mod_export" (or the
equivalent for non-functions).  In my understanding of API's, since
findpwd() is not marked "mod_export", calling it in a module is
undefined behaviour.

What makes this hairy is that zpython's build script appears to depend
on having access to config.h, which upstream has specifically (in the
mail above the one you linked) stated is _not_ a module-facing
interface...  so anything we or upstream do to install only public
headers, is probably going to break the zpython build.  (And I'd rather
not do that; however, I do think the zpython build will have to change
at some point.)

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

For future reference, the mbox-formatted messages are available
directly:

    http://www.zsh.org/mla/zsh-workers/40232

> I don't get why patch thinks that the patch is already applied. It's
> clearly not. Anyone an idea here?

The diff did not apply to your working tree:

% diff -U0 =(GET http://www.zsh.org/mla/workers/2016/msg02716.html | tail -53 | head -27 ) \
           =(caste http://www.zsh.org/mla/zsh-workers/40232) \
  | tail -3
@@ -14 +70 @@
--[if test "`/bin/sh -c \"echo '\\n'\"`" = "\\n"; then
+-[if test "`/bin/sh -c \"echo '\\n'\"`" = "\\n"; then

That said, I'd have expected patch(1) to create *.rej file.

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

Right, I haven't filed a separate bug for that, since I knew I was about
to fix it upstream.  I did add it to the reproducible builds' notes.git,
though.

Cheers,

Daniel