Bug#948894: z3: add nojava build profile

[Fabian Wolff]

Source: z3
Severity: wishlist
X-Debbugs-CC: helmut at subdivi.de

[discussion continued from #948763]

On 1/13/20 7:30 PM, Helmut Grohne wrote:
> Why is the libz3-java package "Architecture: any" (long list actually)
> instead of "Architecture: all"? Many lib*-java packages are
> "Architecture: all" instead, so I'd like to understand the reason.
> 
> Why is the libz3-java package "Multi-Arch: foreign"? It seems to depend
> on libz3-jni, which is "Multi-Arch: same". Such a setup seems wrong as
> both seem to be libraries. As a dependency on libz3-java would be
> expected to provide the jni components for the requested architecture,
> but this is not the case here. Possibly, the "Multi-Arch: foreign" is
> wrong here. In that case, "Architecture: any" does make sense as
> "Architecture: all" cannot propagate an architecture-constraint. (This
> is also known as the multi-arch-interpreter-problem.)
> 
> Why are libz3-java and libz3-jni separate packages? Why not merge them
> into one? In which situations would you install one, but not the other?

First of all, I should note that I have adopted this package not too
long ago from an inactive maintainer, so I'm still somewhat in the
process of cleaning things up (and unfortunately, I can't ask the
previous maintainer about decisions he's made because he won't reply
to any emails).

>From my understanding of what has happened, there used to be a single
libz3-java package that included the shared library in usr/lib/*/jni/,
which is why it had to be Architecture: any. It was also marked
Multi-Arch: same, but because the JAR file in /usr/share/java/ was not
built reproducibly, bug #797515 complained that the JAR file was an
architecture-dependent file in a Multi-Arch: same package. It actually
isn't architecture-dependent, of course, but because the build was
(is?) not reproducible, rebuilding it on different architectures still
yields different results (as does rebuilding on the same architecture).

The previous maintainer's solution to this was to split the libz3-java
package into an Architecture: any, Multi-Arch: same libz3-jni package
containing the JNI shared library and the current libz3-java package
containing only arch-independent files, but because they did not build
reproducibly, they *looked* like arch-dependent files, which is why, I
suppose, he marked the package Architecture: any (instead of all) and
Multi-Arch: foreign (because it's actually not arch-dependent).


Of course, this solution is not very satisfying. Please correct me if
I'm wrong, but I think that the proper solution should consist of a
single libz3-java package marked Architecture: any (because of the JNI
shared library) and Multi-Arch: same (for the JAR file), right?

Apparently [0], JAR files still aren't built reproducibly, but
dh_strip_nondeterminism might take care of this; do you know more
about this? Comparing the amd64 and armhf builds of libz3-java from
snapshot.debian.org actually does suggest that the package is built
reproducibly by now.

Best regards,
Fabian

[0] https://wiki.debian.org/ReproducibleBuilds/TimestampsInJarFiles