Re: Numpy API change?

[Jakub Wilk <jwilk@debian.org>]

* Yaroslav Halchenko <debian@onerussian.com>, 2010-07-22, 10:54:
> > It's true that upload of Numpy 1.4 wasn't done with proper care.
> > However, even if we discovered the breakage earlier, we couldn't
> > avoid sourceful uploads of the affected packages.
> hm... may be we still could...

No. :P

> > BinNMUs only make sense if there is a versioned dependency that will
> > force upgrades and migration in the correct order. We cannot solve the
> > current situation that way: e.g. if we binNMUed python-tables, its new
> > binaries would immediately migrate to testing, which would make them
> > as useless as they are currently in unstable.
> good point -- I did miss that while composing my "solution" email.  BUT
> I think here we still have two possible resolutions atm (Sandro's
> proposal sounds better in the longer run) with different
> trade-offs
>
> 1. binNMU with manual transition (blocking bugs or may be release team
>   block hints) to testing

AFAIK RC bugs are not enough to prevent binNMUed binaries slipping into 
testing; block hints are, and I've already requested to add them:

$ wget -q -O- http://release.debian.org/britney/hints/aba | grep numpy
# requested by jwilk / numpy issues
block h5py mayavi2 nipy petsc4py pytables python-numpy python-scipy scikit-learn

However, I consider this only a temporary measure to prevent the current 
breakage spreading into testing. We *do* need proper versioned 
dependencies.

> 2. sourcefull uploads with hardcoded dependency on specific version of
>   numpy

Hardcoded dependency *and* build-dependency. These two must be in sync, 
obviously. Otherwise, yes, that would work.

> 1. might sound like more work (filing bugs to prevent transition, and
> then closing them whenever 1.4 gets into testing), but 2. involves
> hardcoding of Depends, which
> * also requires time
> * prevents transparent backporting because those versioned depends
>   are there just for the sake of proper transition
>   sid->testing(squeeze)
>
> 1. also would have a somewhat unpleasant effect -- whenever everything
> gets into testing, someone willing to upgrade only dependent package
> would not automagically install numpy 1.4 so his installation might get
> broken.  But in the long run it should be fine

That's why 1 is not acceptable.

I believe we should go ahead with 2 as a solution for squeeze. (We don't 
expect more Numpy transition before the release, do we?) I don't think 
we have time to implement the pydist concept in python-support and 
convert python-central-based packages...

Here are a few other approaches that may or may not make sense:

3. Write dh_numpy (a working prototype attached) and start using it. 

4. Make python helper(s) automatically detect if numpy is being used via 
Cython/Pyrex code and put versioned depends on python-numpy into 
python:Depends if this is the case.

--
Jakub Wilk

#!/usr/bin/perl -w

use strict;
use File::Find;
use Debian::Debhelper::Dh_Lib;

init();

my $numpy_next_version;
my $numpy_version = `python -c 'from numpy import __version__; print __version__'`;
if (! defined $numpy_version || $numpy_version eq "")
{
    error("Numpy is not installed, aborting. (Probably forgot to Build-Depend on python-numpy.)");
}
elsif ($numpy_version =~ m/^(\d+)[.](\d+)([.]\d+)*/)
{
    $numpy_version = sprintf("%d.%d", $1, $2);
    $numpy_next_version = sprintf("%d.%d", $1, $2 + 1);
}
else
{ 
    error("Unable to parse Numpy version out of \"$numpy_version\".");
}

foreach my $package (@{$dh{DOPACKAGES}})
{
    addsubstvar($package, "numpy:Depends",
        "python-numpy (>= $numpy_version), " .
        "python-numpy (<< $numpy_next_version)"
    );
}

# vim:ts=4 sw=4 et

Attachment: signature.asc
Description: Digital signature