Control: tags -1 - patch Hi Dmitry,
Thank you for your quick and insightful reply. Please Cc debian-cr...@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)
