[Python-modules-team] Bug#915856: sphinx: Failed cross building with Build-Depends on python3-sphinx

[Dmitry Shachnev]

Hi Helmut!

On Sun, Jan 20, 2019 at 10:12:09AM +0100, Helmut Grohne wrote:
> Hi Dmitry,
>
> Thank you for contacting me about this issue. It is a very relevant one
> that I have neglected far too long, because I felt it was too difficult.
> That shouldn't stop us from working on it however and I'm really happy
> to help solve it. Beware that disruptive changes may be ahead though.

Thanks for responding quickly!

> > 2) After doing that, you can no longer use dh --with sphinxdoc, as dh will
> > not find sphinxdoc.pm. So you will need something like this instead:
>
> There actually is a way to use the addon.
>
> DH_ADDONS=
> %:
> 	dh $@ $(DH_ADDONS)
> build binary %-indep: DH_ADDONS+=--with=sphinxdoc

The only thing sphinxdoc.pm does is calling dh_sphinxdoc after dh_installdocs,
so this is equivalent to my approach.

> > 3) Also maybe you will need to pass --binary-indep to pbuilder, as it does
> > not automatically add that option for cross builds.
>
> Since very recently, sbuild automatically adds --no-arch-all for cross
> builds. Not sure about the situation of pbuilder.

Ack.

> > > So maybe we can say that architectures don't matter for sphinx by
> > > marking it Multi-Arch: foreign? Unfortunately, no. python-sphinx
> > > transitively depends on python-markupsafe (via python-jinja2) and thus
> > > exposes it. Since python-markupsafe is an architecture dependent Python
> > > extension, python-sphinx exposes the architecture. This is the gist of
> > > the multiarch interpreter problem.
>
> Please consider this just as one example. I looked through the
> dependency stack and this was the first example found. There is likely
> more underneath.

I think the rest of Sphinx dependency stack is pure Python (not counting
some compiled parts of Python standard library).

> I'm quite sure that by now marking python3-sphinx M-A:foreign is wrong
> for precisely the reason you give: You don't know ahead of time whether
> you'll have to import architecture-dependent code.

Ack.

> These are two questions:
>
>  * If a package is M-A:foreign, do all dependencies have to be
>    M-A:foreign?
>
>    No! I often use dependencies not being M-A:foreign as an argument,
>    but that is only an approximation. What really counts is the
>    "interface" of a package. Unfortunately, "interface" is pretty
>    loosely defined in Debian so a conservative approach is to treat all
>    dependencies as part of the "interface". So having all dependencies
>    M-A:foreign is part of a sufficient, but not necessary argument.
>
>  * Should there be a M-A:foreign sphinx package?
>
>    Likely, that'd be a good idea. It must be done with care however. It
>    must be made abundantly clear that combining sphinx (as opposed to
>    python3-sphinx) with any sphinx extension is a serious bug. Using a
>    sphinx with a sphinx extension is akin to a "missing dependency" and
>    we usually call that an rc bug. (The missing dependency is
>    python3-sphinx of course.) As a result, this approach is only useful
>    for "simple" packages. It can be a partial solution and most cases
>    can likely use either plain "sphinx" or split a -doc package.

Most Sphinx extensions are pure Python too. However, as I said, the autodoc
extension is pure Python itself but may import code from the source package
being built, which may be not pure Python.

Now there is no binary package named “sphinx”. The executable files are
provided in python-sphinx and python3-sphinx binary packages, and are
managed by alternatives system (Sphinx 2.0 will drop Python 2 support, so
only python3-sphinx will remain). Are you suggesting to split these files
into a separate binary package?

> A "weaker" alternative already employed by some other python extensions
> is "Multi-Arch: allowed". It's essentially the same thing just renaming
> "sphinx" to "python3-sphinx:any". It'll look more ugly in dependencies,
> but it crucially is the same thing.

Is it safe to add Multi-Arch: allowed to python-sphinx and python3-sphinx
right now (and Multi-Arch: foreign to sphinx-common)?

> The heart of the problem is the multiarch interpreter problem though.
> What you want to express here is that a number of dependencies must have
> a common architecture, but can differ from other packages. In a sense,
> we'd want group dependencies together and have the user select the
> architecture for each group. We discussed this extensively at least in
> Vaumarcus and concluded that the problem is too hard. Whenever you need
> such a thing, you have to create a "dependency package" depending on all
> packages in the group and making that dependency package Multi-Arch:
> foreign. Now creating such dependency packages for every subset of
> sphinx extensions is not gonna work obviously. I don't think this is
> entirely solvable. Therefore I propose concentrating on practical,
> individual, and relevant cases. Your suggestion to split -doc packages
> is a very good one in that respect.

If you need help with this (e.g. filing bugs/patches to split -doc packages),
please let me know.

--
Dmitry Shachnev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/python-modules-team/attachments/20190120/e967a41f/attachment.sig>