Hi, Quoting Emilio Pozuelo Monfort (2020-03-30 13:24:01) > We've just finished the transition to python3.8 as the default python3 > interpreter, which was a bit difficult due to some autopkgtest regressions in > a few rdeps, and to the fact that many modules only build their extensions > for the default python version, which means they have a strict dependency on > the python3 version[1] and they need to be rebuilt and migrated in lockstep > with python3-defaults. > > I have analyzed this based on current sid amd64 contents and have come up with > the following packages that don't ship extensions for both py3.7 and 3.8 (which > are the currently supported versions). Note that pure python packages that don't > build C extensions are not affected. > > It would be great if this situation can be improved in order to help with future > python transitions. Building for all the supported python versions can be done > by build-depending on python3-all-dev and compiling your package (or just the > python bits) with PYTHON pointing to each version. Depending on your package's > build system, this could be largely automated using some helper, such as > pybuild. If you don't know how to add support for your package, feel free to ask. does this mean that build-depending on python3-dev is wrong in general and should instead be replaced by build-depending on python3-all-dev? Could wrong build dependencies or binary packages which have a strict dependency on a python3 version not easily be detected by lintian? I'm not an expert in Python module packaging -- it just so happens that some packages I maintain offer Python bindings. Do you have a diff of a source package that successfully made the transition so that I know what I would have to change? For example the package src:ros-geometry2 has a super simple dh-style rules file, basically just doing: %: dh $@ --buildsystem=cmake --with python3 What would I have to change to successfully fix this problem? Thanks! cheers, josch
Attachment:
signature.asc
Description: signature