On 3/30/20 1:24 PM, Emilio Pozuelo Monfort wrote: > Hi, > > 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.
Yes, that would be useful. However there are only limited time windows when you can do *and* check such work, i.e. when the python3-defaults package has two supported python3 versions. Filing and fixing these issues would be nice. Plus for most of those packages you have to modify the build system to build the package for each python3 version, or to just build the extension for the non-default version. I assume we still could keep 3.7 as a supported python3 version for some time, if people want to work on those issues. But people probably won't have the time to work on that when we introduce 3.9. Matthias
