Bug#951829: don't explicitly request python 3.7 for the build
Control: severity -1 normal
On Fri, Mar 27, 2020 at 12:57 PM Emilio Pozuelo Monfort
<pochu@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 <malat@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,
Reply to: