[Python-modules-team] Bug#643873: Making Numpy transition less painful
jwilk at debian.org
Fri Sep 30 15:17:50 UTC 2011
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.
python-numpy would provide two virtual packages:
- python-numpy-abi$N and
$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).
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.
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. :/
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.
More information about the Python-modules-team