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

Dmitry Shachnev mitya57 at debian.org
Sun Oct 23 17:51:43 UTC 2016


Hi Helmut,

On Thu, Oct 20, 2016 at 09:09:03PM +0200, Helmut Grohne wrote:
> Hi Dmitry,
>
> I'm still kinda split about this. I discussed this with Guillem Jover
> and Ian Jackson at length to avoid that step and still don't like it.

Same for me.

> > Do you have any use cases where the documentation should be built in
> > build-arch target, rather than build-indep (which is only run for arch-indep
> > builds)?
>
> Unfortunately, yes. python-sphinx has ~700 build-rdeps. We can simply
> under approximate those that need python-sphinx during build-arch by
> ignoring all packages that build architecture independent packages. That
> leaves at least 25 affected packages:
>
> axe-demultiplexer buildbot cvxopt lava-dispatcher liblognorm mayavi2
> minieigen mydumper pathspider portabase py-postgresql pyalsaaudio
> pynifti python-brainstorm python-chaco python-enable python-prctl
> python-srp python-traits salmon squirrel3 trafficserver tsung urwid
> vmdebootstrap

To be honest, I think 25 (of ~700) is a small enough number.

> Of these, liblognorm is a high popcon package that specifically fails
> cross building, because its python-sphinx dependency is cross
> unsatisfiable.
>
> If we can avoid turning python-sphinx Arch:any, then I'm all for it. So
> which route shall we pursue now? I basically see three:
>  * Split documentation packages out of the above.
>  * Turn python-sphinx arch:any and annotate python-sphinx dependencies
>    with :native.
>  * Change dependency resolution in general. Update dpkg, apt, dose3. For
>    instance allowing :native annotations on Arch:all packages would
>    suffice.
>
> Indeed, I do like moving documentation to Arch:all packages, but I'm not
> sure we want even more small binary packages.

It usually does make sense to split the documentation. One reason for it
is to avoid dependency of the main package on JS stuff like jQuery and
underscore.

Another reason, for non-Python packages, is to allow “light” builds without
documentation (and without Sphinx/Python B-D) if the “nodoc” build profile
is used.

So I think the first option is not so bad as it may seem.

I cannot tell anything about the other two options, you probably know
better than me whether they are realistic or not.

--
Dmitry Shachnev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/python-modules-team/attachments/20161023/cd8745f9/attachment-0001.sig>


More information about the Python-modules-team mailing list