Packages requiring numpy may require a rebuild in f13 and rawhide

David Malcolm dmalcolm at redhat.com
Fri Apr 2 15:54:02 UTC 2010


On Fri, 2010-04-02 at 04:11 -0800, Jeff Spaleta wrote:
> On Thu, Apr 1, 2010 at 11:03 PM, Jussi Lehtola
> <jussilehtola at fedoraproject.org> wrote:
> > A Python package BuildRequiring numpy does not need to mean anything.
> > All of my packages on the list BuildRequires numpy simply because the
> > install scripts have a dummy check in them for checking that all
> > necessary runtime modules are installed.. so AFAIK nothing is compiled
> > against numpy.
> 
> I'm not saying all those packages are affected... I'm saying that's a
> starting point for packages to be checked.
> 
> The ABI break is real.  Quoting scipy.org:
> "NumPy 1.4.0 release pulled. (2010-2-8) Due to an unintended ABI break
> the 1.4.0 release has temporarily been pulled pending a decision on
> how to handle the ABI incompatibility."
> 
> Its almost two months later and NumPy 1.4.0 is still pulled from
> upstream. Not a good sign. Do we revert to back to to the old version
> if upstream doesn't re-release 1.4 before F13 release date? Sort of an
> important question.
> 
> I'm still coming up to speed on the details by reading the upstream mailinglist.

I haven't looked into the ABI break in detail, but I notice that our
"numpy" rpm contains header files:
[david at f13 ~]$ rpm -q numpy
numpy-1.4.0-4.fc13.x86_64
[david at f13 ~]$ rpm -ql numpy|grep "\.h"
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/__multiarray_api.h
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/__ufunc_api.h
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/_neighborhood_iterator_imp.h
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/_numpyconfig.h
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/arrayobject.h
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/arrayscalars.h
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/ndarrayobject.h
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/noprefix.h
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/npy_common.h
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/npy_cpu.h
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/npy_endian.h
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/npy_interrupt.h
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/npy_math.h
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/npy_os.h
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/numpyconfig.h
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/old_defines.h
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/oldnumeric.h
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/ufuncobject.h
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/utils.h
/usr/lib64/python2.6/site-packages/numpy/numarray/numpy/arraybase.h
/usr/lib64/python2.6/site-packages/numpy/numarray/numpy/cfunc.h
/usr/lib64/python2.6/site-packages/numpy/numarray/numpy/ieeespecial.h
/usr/lib64/python2.6/site-packages/numpy/numarray/numpy/libnumarray.h
/usr/lib64/python2.6/site-packages/numpy/numarray/numpy/numcomplex.h
/usr/lib64/python2.6/site-packages/numpy/numarray/numpy/nummacro.h
/usr/lib64/python2.6/site-packages/numpy/random/randomkit.h


...which define the C-level API and data layout of the various useful
PyObject subclasses provided by NumPy.

For example, 
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/ndarrayobject.h
contains the declaration of struct PyArrayObject and the API to go with
it, which extension modules may be using.

Would it help insulate against future changes if these headers were
moved to a numpy-devel subpackage?  That way, packages that need to have
a direct binary API dependency would need a BuildRequires: numpy-devel
whereas those that merely go in at the Python level wouldn't need this,
and it would be easier to spot packages needing a rebuild.

Doing so now and forcing a rebuild _might_ help isolate the change.  I
don't know if that's a good idea at this stage for F-13, though.

Hope this is helpful; I haven't had enough coffee yet today so I may be
missing something.

Dave



More information about the devel mailing list