Bug#948763: z3: cannot be built on buildds

[Helmut Grohne]

Control: retitle -1 cannot migrate to testing

Hi Fabian,

On Mon, Jan 13, 2020 at 04:27:15PM +0100, Fabian Wolff wrote:
> On Mon, 13 Jan 2020 06:21:56 +0100 Helmut Grohne <helmut at subdivi.de> wrote:
> > Source: z3
> > Version: 4.8.7-3
> > Severity: serious
> > 
> > z3 cannot be built on buildds, because its Build-Depends cannot be
> > satisfied on buildds. Failing to build on buildds is a serious problem.
> 
> It builds now on all but three architectures, including, in particular, all
> release architectures.

Oh, I'm wrong here. It did build. But the dependency issue prevents it
from migrating to testing. So you want to fix that anyway.

> Thanks for your suggestions, but I'm not very familiar with how Multi-Arch
> annotations should be used; I just accepted a patch to make the z3 package
> more cross-build friendly (see #948109).

That bug is not at all about cross building nor multi-arch. It seems you
(and your contributors) are conflating multiple issues. Things become
much easier once you start separating them.

> Can you give me a patch where you set the build dependency annotations in a
> sound way that also works for cross-building? Otherwise, I would have to
> simply remove all annotations again in order to fix this bug (but clearly,
> that would not be the most desirable solution).

No. The expectation that every package can be cross built is misguided.
z3 uses java stuff, which is an unsolved problem. Therefore you cannot
make z3's dependencies cross-satisfiable at this time. If you want to do
so anyway, be prepared to invest quite some work.

For this reason, reverting the annotations is not the worst of options.

> I would also be happy to use the nojava build profile that you suggested,
> but again, I'm not familiar with this technique, and from what I've heard,
> there are still some problems e. g. with using "dh-sequence-javahelper
>  <!nojava>". But if somebody gave me a patch, I'd be happy to apply it.

That seems like a sensible path forward, but I lack the domain-specific
knowledge about z3 to do that. This situation has happened before (e.g.
with texlive maintainer Norbert Preining): He lacked knowledge of
multi-arch and I lacked knowledge about texlive. We started discussing
things and learned from one another. In that process we figured out how
to make multi-arch work for parts of texlive. What I'm trying to say is:
I cannot give you a patch. We can only get there together and I'm happy
to help.

If we want to move forward with <!nojava>, I have a few questions. If
you intend to answer them, please clone a new bug for that. This bug is
about fixing the wrong Build-Depends annotations.

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?

When we talk about multi-arch or build profiles, we need to have a good
understanding of what the relevant interfaces of packages are. My
questions aim at clarifying that.

Helmut