Source: z3 Severity: wishlist X-Debbugs-CC: hel...@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
