[Python-modules-team] Bug#818115: turn python-sphinx into an arch:any package
Dmitry Shachnev
mitya57 at debian.org
Thu May 12 10:34:04 UTC 2016
Hi Helmut,
On Mon, Mar 14, 2016 at 07:05:11AM +0100, Helmut Grohne wrote:
> Hi Dmitry,
>
> Thank you for your quick and insightful reply.
As you can see, I don't always reply quickly. Sorry for the delay this time.
> 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.
I like the plan, though the third point can be avoided if dh_sphinxdoc is
called only during arch-indep build.
> 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.
161 is many packages, though in my opinion splitting the documentation into
arch:all packages is something that should be done independently of this bug.
Maybe we can have some kind of DD list whose packages are affected by this?
(Or a Lintian warning, see below.)
> 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.
I do not like it too... But I will try to do as much as possible from my side
to resolve this problem.
> Do you have any preferences on the approaches sketched above keeping in
> mind that we will apply it to hundreds of packages?
In an ideal world, the solution looks this way:
1) Packages shipping Sphinx documentation in arch:any packages should
split it into arch:all packages.
2) All packages using Sphinx should make sure dh_sphinxdoc is only called
during arch-indep build.
For 1), maybe we can have a Lintian warning for that?
(i.e. sphinx-documentation-in-architecture-dependent-package)
For 2), this means packages having both arch-dep and arch-indep packages won't
be able to use --with sphinxdoc because sphinxdoc.pm sequence won't be present
during arch:indep build. We can recommend packages to insert it manually then,
like:
override_dh_installdocs-indep:
dh_installdocs -i
dh_sphinxdoc -i
Alternatively, as you suggest, such packages may build-depend on sphinx-common
and I may mark sphinx-common as Muili-Arch: foreign. If it helps then I will
do that.
--
Dmitry Shachnev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/python-modules-team/attachments/20160512/1b4058e6/attachment.sig>
More information about the Python-modules-team
mailing list