On Fri, 2010-04-02 at 04:11 -0800, Jeff Spaleta wrote: > On Thu, Apr 1, 2010 at 11:03 PM, Jussi Lehtola > <jussilehtola@xxxxxxxxxxxxxxxxx> 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@f13 ~]$ rpm -q numpy numpy-1.4.0-4.fc13.x86_64 [david@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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
