On Fri, Aug 24, 2018 at 10:05:23AM -0300, Andreas Hasenack wrote:
> while investigating some DEP8 failures currently in cosmic's
> migration, I came across this:
> $ dpkg -s python3-numpy|grep Depends
> Depends: python3 (<< 3.8), python3 (>= 3.6~), python3.6:any,
> python3.7:any, python3:any (>= 3.3.2-2~), libblas3 | libblas.so.3,
> libc6 (>= 2.27), liblapack3 | liblapack.so.3
> Is it ok/correct to depend on two python versions like that? Is the
> point of it making sure numpy is available regardless which python 3
> you are using? But at the cost of pulling in both?
> This is breaking python3-libcloud, which does not support python3.7,
> when pulled in via fdroidserver:
> The correct fix is to have python3-libcloud work with python 3.7, by
> replacing "async" (a reserved keyword in python3.7) with something
> else, like async_, but what caught my eye was this numpy dependency in
> two python versions. And how libcloud ended up chosing 3.7 over 3.6
> I'm not sure.
This issue was reported in Debian during the previous python transition, and
was closed without a permanent resolution:
And a bug is now open again about the same issue wrt the python3.7
I agree that the current behavior is incorrect and not what we expect from
packages that support multiple versions of python3.
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/