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
signature.asc
Description: signature
