[Python-modules-team] Bug#643873: Bug#643873: Making Numpy transition less painful

[Sandro Tosi]

Hello Jakub,
sorry for this very late reply.

I'm adding in the loop debian-python, so that we can hear others
opinion (and pretend we're still a team :) ).

First of all, let me say: I like your idea! in the reply (full, for
new readers) my comments.

On Fri, Sep 30, 2011 at 17:17, Jakub Wilk <jwilk at debian.org> wrote:
> Source: python-numpy
> Version: 1:1.5.1-2
> Severity: normal
>
> Numpy transitions are currently very painful: they involve large number of
> packages, and they need to happen even when Numpy *didn't* break binary
> compatibility. Here's my proposal to improve this situation.
>
> Virtual packages
> ================
> python-numpy would provide two virtual packages:
> - python-numpy-abi$N and
> - python-numpy-api$M.
> $N would be changed each time C_ABI_VERSION is changed upstream, and $M
> would be changed each time C_API_VERSION is changed upstream.
>
> Dependencies generated by dh_numpy
> ==================================
> dh_numpy would generate dependency either on "python-numpy-abi$N" (by
> default) or on "python-numpy-api$N" (if a special option, say, --strict, is
> used). The second option would be needed for packages which are overzealous
> at checking ABI unless/until we fix them (we have at least one package in
> the archive which does that).

do you think it's possible for the same source package to generate 2
binaries one needing python-numpy-abi$N and the other needing
python-numpy-api$N ? how would you imagine to handle this? with
"dh_numpy -pbin1 --strict\ndh_numpy -pbin2" or something else?

> Avoiding strict dependencies for arch:all packages
> ==================================================
> dh_numpy should not generate any dependencies in arch:all packages. Such
> packages cannot rely on Numpy ABI, and rebuilding them for transition
> purposes is causes lot of trouble. (We already had to do this in the past!)
> For the same reason, /usr/share/python/dist/python-numpy needs to go away.

so just a python-numpy added to python:Depends? how does it fix with a
source that generates an arch:all and an arch:any (the latter using
either -abi or -api)?

> Open problems
> =============
>
> Virtual package names
> ---------------------
> How should $N and $M be generated? At least C_ABI_VERSION seems to be a big
> integer, at it'd look ugly if we used is an $N. :/

Yeah, I can talk about that with upstream, in particularly because
maybe they only increment the right-most digit and don't do big jumps.
Else, we can just start with 1 for both and use it only for Debian
purpose.

> Gracefully handling the upcoming transition
> -------------------------------------------
> A number of packages in the archive already has dependency on "python-numpy
> (<< 1:1.6)", which is not satisfiable by the package in experimental. To
> avoid this transition (or at least reduce its size) we could do one of two
> things:
> 1) Implement the proposed changes first in unstable, schedule binNMUs, then
> upload Numpy 1.6 to unstable.
> 2) Implement the proposed changes only for Numpy 1.6, but make dh_numpy
> generate alternative versioned dependencies:
> "python-numpy (>= 1:1.5.1), python-numpy-abi$N | python-numpy (<< 1:1.6.2)".
> Then upload Numpy 1.6, schedule binNMUs.

Mh, my lazy instinct would say 2) that has also the advantage to bring
1.6 into unstable (but I guess 1.7 is coming soon).

Please also note taht my perl foo is barely None, so I'd need some
help in extending dh_numpy :)

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi