Hi Dmitry, On Sun, Jan 20, 2019 at 06:21:27PM +0300, Dmitry Shachnev wrote: > Now there is no binary package named “sphinx”. The executable files are > provided in python-sphinx and python3-sphinx binary packages, and are > managed by alternatives system (Sphinx 2.0 will drop Python 2 support, so > only python3-sphinx will remain). Are you suggesting to split these files > into a separate binary package?
Upon closer inspection, I'm growing doubts. The autodoc extension is not in some python3-sphinxcontrib.something package but in python3-sphinx proper. Therefore you want a way of using a particular architecture's sphinx anyway. Marking it M-A:foreign is likely going to cause trouble later on. So if you split out this sphinx package, you'd likely have python3-sphinx Depends: sphinx at least initially. Without that dependency, lots of packages will FTBFS. Then sphinx would of course Depends: python3-sphinx posing a circular dependency until we fix all those FTBFS. Then any package that refers to the scripts and uses autodoc must "Build-Depends: sphinx, python3-sphinx". This is confusing at the very least. Certainly not something we want to do before buster. > > A "weaker" alternative already employed by some other python extensions > > is "Multi-Arch: allowed". It's essentially the same thing just renaming > > "sphinx" to "python3-sphinx:any". It'll look more ugly in dependencies, > > but it crucially is the same thing. > > Is it safe to add Multi-Arch: allowed to python-sphinx and python3-sphinx > right now (and Multi-Arch: foreign to sphinx-common)? I overlooked one major issue with Multi-Arch: allowed. The value is not permitted on Architecture: all packages. So if you trying using it, you end up switching python3-sphinx to Architecture: any. Beyond that, the marking is certainly not doing any immediate harm. Until some other package uses "python3-sphinx:any" literally nothing changes. As soon as you get such a dependency however, reverting becomes difficult. Removing "Multi-Arch: allowed" will make all "python3-sphinx:any" dependencies immediately unsatisfiable (even natively). For Build-Depends, you can use "python3-sphinx:native" now. Until very recently that wasn't possible as dpkg-checkbuilddeps would reject :native annotations on Architecture: all packages, but dpkg has adjusted behaviour to what apt and dose do now. Therefore such dependencies harm stretch-backports. Still it might be the best thing we have at the moment. > If you need help with this (e.g. filing bugs/patches to split -doc packages), > please let me know. Well, we do have some data on which packages are affected. Carefully open this huge html file: https://bootstrap.debian.net/cross_all.html. Then search for "python3-sphinx" and you get an overview of which packages are affected. It currently is the #10 cross unsatisfiable cause with 146 affected packages. Searching again will reveal the actual source packages. Note that the list already excludes Build-Depends-Indep as well as source packages that only build architecture-independent binary packages. Carefully pick valuable targets here. For instance large documentation trees, long build time, high popcon. There is a reason why I have - for a long time - not actively worked on cross/sphinx: There is no obvious solution. I wish I could give more encouraging answers. Helmut _______________________________________________ Python-modules-team mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
