Bug 207899 - NumPy package missing some important header files
NumPy package missing some important header files
Product: Fedora
Classification: Fedora
Component: numpy (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jarod Wilson
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2006-09-25 04:39 EDT by Peter Williams
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: 0.9.8-1.fc5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-25 12:57:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Peter Williams 2006-09-25 04:39:32 EDT
The Extras package of numpy does not include certain development headers
normally installed by a manual build of numpy. These headers include:


I actually saw this while trying to build a package for the updated numpy-1.0rc1
release, but I believe it is still an issue with the current version; and if it
isn't, it will become one in the future.

The problem is that Python distutils suck, basically. In particular, the
'install' command is run with --skip-build to not (stupidly) rebuild most files.
But when the build step is not run, the list of files is not completely
populated, so 'setup.py install --skip-build' only installs a subset of the
files installed by 'setup.py install' with no arguments. This is of course
completely broken, but it must be worked around. The relevant file is
numpy/core/setup.py. A glance will show that there are calls to
config.add_data_files() sprinkled throughout; this code apparently does not get
executed in --skip-build mode.

One solution would be to patch that file to call config.add_data_files() in
install mode; but I do not know enough about distutils to know where such calls
should be added.

Alternatively, the install step could be run without the --skip-build flag. This
will make the build take much longer, but it is a more futureproof solution.
Seeing as the build time never affects users, I think this is the best option,
although it is infuriating that the distutils are this badly designed.
Comment 1 Peter Williams 2006-09-25 04:41:29 EDT
Add Ignacio to CC-list since he seems to be the person in charge of the RPM spec

By the way, I'm pretty sure that nothing that references the NumPy C API can be
built against the current numpy package. I know that SciPy cannot be built, at
Comment 2 Jarod Wilson 2006-09-25 12:57:20 EDT
Apparently, I forgot to push numpy 0.9.8 over to fc5 when I built it for
rawhide, so I presume you were trying to build against a somewhat outdated
version of numpy. Everything is just fine with the latest rawhide build, no need
to remove the --skip-build flag. I'll push through a new build for fc5, which
also checks out locally.

$ rpm -qpl /build/RPMS/x86_64/numpy-0.9.8-1.fc5.x86_64.rpm |egrep

Oh, and Ignacio was the package maintainer, but he's gone MIA, and I've since
taken it over.
Comment 3 Jarod Wilson 2006-09-25 13:13:10 EDT
For the anxious, who want at the updated packages before they make it over to
the actual Extras yum repositories:

Comment 4 Peter Williams 2006-09-25 13:14:07 EDT
Hm. I saw this issue using the spec file for 0.9.5 to build a package of 1.0rc1.
So my numpy source is even more up-to-date than yours, but my spec file is
older. Maybe there's something a little nonstandard about my environment. I
guess I'll see if the next Extras packages have the files or not. (Speaking of,
any chance that an update for 1.0rc1 will be pushed? Or is everything pretty
much holding for FC6?)
Comment 5 Jarod Wilson 2006-09-25 13:20:13 EDT
I'll put a 1.0 build together once its final, starting with FC6, but probably
followed closely by an FC5 build. Generally speaking, I'd rather stick to
released versions, but there seems to be quite a bit of demand for a numpy
1.0-ish package... I *might* do a 1.0rcX package for FC6...

Note You need to log in before you can comment on or make changes to this bug.