Control: severity -1 normal On Fri, Mar 27, 2020 at 12:57 PM Emilio Pozuelo Monfort <po...@debian.org> wrote: > > Control: reopen -1 7.0.0-1 > Control: retitle -1 python3-openvdb: build against the default python3 version > > On Mon, 24 Feb 2020 11:10:49 +0100 Mathieu Malaterre <ma...@debian.org> wrote: > > Control: tags -1 + patch > > Control: retitle -1 replace python3-all-dev with python3.7-dev > > Err, that's not really the solution. > > The not ideal solution was to build for the default python version, i.e. > build-depend on python3-dev and use python3. That would have built against > python3.7 when that was the default, and against python3.8 now that it has > changed. And with a binNMU from the release team, you wouldn't have even > noticed.
Oh ok. I missed that. > The ideal solution is to build against python3-all-dev and build for *all* > supported python versions. So that when python3.7 and python3.8 are both > supported, you build the python extension for both of them. Just for later reference. Doing so would imply going the kde package style (eg. pykde4), which means somehow importing the "overriden_command" from dhmk.mk (pkg-kde-tools). After that doing lots of boilerplate code to execute $(foreach) on all python version, just because python3.8 cannot deal with a python3.7 module. Given that openvdb is a beast to compile (mips64el even failed), a beast to execute unit test there is no possible way a double compilation + double testing will ever work on those arches, I am marking this solution as wontfix. I'll go ahead and implement the previous solution where a binNMU is required. Thanks,
