Re: Bug#818115: turn python-sphinx into an arch:any package
Control: tags -1 - patch
Hi Dmitry,
Thank you for your quick and insightful reply.
Please Cc debian-cross@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
Build-Depends-Indep.
* 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
solution.
Do you have any preferences on the approaches sketched above keeping in
mind that we will apply it to hundreds of packages?
Helmut
[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)
Reply to: