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