[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