[Python-modules-team] Bug#961206: improve sphinx usage for cross building

Helmut Grohne helmut at subdivi.de
Tue May 26 18:42:30 BST 2020


Hi Dmitry,

On Tue, May 26, 2020 at 02:46:28PM +0300, Dmitry Shachnev wrote:
> It would be nice to have a better estimate of how many packages can be
> fixed in an automated way in DPMT [1], how many packages cannot be fixed
> at all (e.g. because they use sphinx from Python interface) and how many
> packages are remaining.
> 
> [1] Ondřej Nový did the previous mass change that changed ‘sphinx-build’
>     to ‘python3 -m sphinx’ in debian/rules, perhaps it would be easy for
>     him to revert that change and at the same time update the build
>     dependency.

Given that many packages use python3 -m sphinx now, the breakage would
be quite small actually. Using python3 -m sphinx would continue to just
work after the split (though it would still break cross building). So I
guess, we can simply remove DPMT from the calculation.

> The first step (making python3-sphinx provide sphinx) is zero cost, so
> I can do it quite soon.

Doing so enables depending on sphinx, but python3-sphinx and sphinx
actually need to be distinct packages, because sphinx should become
Multi-Arch: foreign while python3-sphinx should not. You cannot express
that using Provides.

> update-alternatives is no longer needed because Sphinx no longer supports
> Python 2.

I guessed that.

> Do you know what is the process of switching from update-alternatives
> to directly shipping the symlink? Can I just drop the postinst/postrm
> scripts and add that symlink, or I need to somehow unregister the
> alternative when the package is upgraded?

I think you need to actually declare Conflicts (not just Breaks and
Replaces) on any alternative (i.e. python-sphinx). Then, you'd remove
the alternative in preinst (like you do in prerm already) and unpacking
the symlinks should work.

Helmut



More information about the Python-modules-team mailing list