On 30.06.2017 22:00, Tristan Seligmann wrote: > Control: severity -1 important > > On Fri, 30 Jun 2017 at 19:33 Scott Kitterman <deb...@kitterman.com> wrote: > >> Technically, it builds, but in a way that's not useful. It would actually >> be >> better if it had failed (I noticed this from reviewing build logs after the >> python3 interpreter depends weren't generated correctly). >> > > In fact, the package works fine on python3.5 as well as python3.6 (the > module imports, and the full test suite passes against the installed > modules), thus I'm downgrading the severity of this bug. > > During the build, the extension modules are first built on python3.5, and > it is these modules that land in /usr/lib/python3, with the "abi3" ABI tag. > The extension modules are then built again on python3.6, but these don't > get moved into /usr/lib/python3 due to the files from the python3.5 build > having the same name, thus landing in an incorrect directory in the final > package and serving no useful purpose. > > The reason the package still works is the "abi3" ABI tag; these modules > (like all CFFI-built modules, by default) are using the Python 3 "stable > ABI"[1] so the modules built on python3.5 work fine when imported on > python3.6, and vice-versa. I think what this means is that we only need to > run the Python 3 build once (using the default version?); also, I think the > interpreter depends are in fact correct in light of this. I tested > downgrading to 1.7.1-3 and the module still imports and works on python3.6, > even though 1.7.1-3 was only ever built against python3.5. > > However, testing against all supported versions at build time is probably > still appropriate. > > I'm looping in debian-python here as others may be surprised by this > combination of effects as well, and we should probably be handling the > issue of modules using the stable ABI consistently. Also, I'm not 100% > certain what the best way forward is here; teach pybuild/dh_python3 about > the stable ABI?
I think testing the build against all supported python versions makes sense. But how do we make sure that a package built against the new supported version end up in the archive for a release? Matthias
