[Python-modules-team] Bug#818115: turn python-sphinx into an arch:any package

Helmut Grohne helmut at subdivi.de
Mon Mar 14 06:05:11 UTC 2016

Control: tags -1 - patch

Hi Dmitry,

Thank you for your quick and insightful reply.

Please Cc debian-cross at lists.debian.org.

On Sun, Mar 13, 2016 at 10:21:58PM +0100, Dmitry Shachnev wrote:
> I wonder what's the point of cross-building the arch-indep packages at all?
> In jansson case, it looks like python-sphinx should be moved from Build-Depends
> to Build-Depends-Indep, and the arch-any packages will be correctly cross-built
> without sphinx.

Cross building only applied to arch-dep packages. So in jansson's case,
it is not about libjansson-doc, but about the other packages. The only
part of sphinx that is actually used during a cross build of jansson
actually is the debhelper addon, which actually lives in sphinx-common
and is exposed by python-sphinx. In a very similar case, Tomasz Buchert
was able to move python-sphinx from Build-Depends to Build-Depends-Indep
in nghttp2[1]. So looking at this closer again, a potential solution for
sphinx could be:

 * Mark sphinx-common Multi-Arch: foreign.
 * Move python-sphinx from jansson's Build-Depends to
 * Add sphinx-common to jansson's Build-Depends.

I didn't verify whether these changes are correct. We can try this to
put urgency out of the loop.

> If there are other cases except jansson, please let me know. Though I can't
> imagine how sphinx can be used for building something arch-specific…

If it were just jansson, I would certainly have spent more time on a
workaround there. But we are talking about 161 source packages[2]. It
seems highly likely that a significant fraction of them do not split
their sphinx generated documentation into Arch:all packages.

In principle, it would be even enough if python-sphinx could be made
Multi-Arch:allowed and having dependencies annotated with :any. But if I
am reading the multiarch spec correctly, we cannot use allowed on
arch:all packages.

In a sense, Multi-Arch: allowed is an optimization though. The same
effect can always be achieved by another layer of indirection. Put up an
empty arch:all package python-sphinx-any (or maybe rather just sphinx),
have it depend on python-sphinx, mark it Multi-Arch: foreign and clearly
document that consumers may only depend on it when interfacing with
sphinx through the command line interface exclusively. An example for
this is gcc-for-build, which uses the package description to document
what can be expected.

> (Also, if I just apply the change you suggested, sphinx will FTBFS on some
> archs, because the tests use webkit which segfaults there — so it's a bit more
> tricky).

Patch tag removed accordingly. Any solution will need more thought then.

I do not like the proposed solution at all. That is why I hesitated more
than two years after recognizing that it would indeed fix things before
actually sending a bug. I would certainly love to see a different

Do you have any preferences on the approaches sketched above keeping in
mind that we will apply it to hundreds of packages?


[1] https://anonscm.debian.org/cgit/collab-maint/nghttp2.git/commit/?id=38b8cce3978bf017d6bf806d70f46696e59f04c2
[2] http://bootstrap.debian.net/cross_all.html (look for python-sphinx
    in the last column of the first table)

More information about the Python-modules-team mailing list