Hi Orion, I don't know the "right" answer to the include files.  I suppose 
it would be good to look at how other people package Python headers.  Or, 
maybe someone can step in and explain whats best...?

I did manage to build it on FC-4 and rpmlint threw up a handful of warnings 
and two errors:

  W: python-numarray devel-file-in-non-devel-package
     /usr/include/python2.4/numarray/arrayobject.h

  ...more devel-file-in-non-devel-package warnings skipped...

  E: python-numarray backup-file-in-package
     /usr/share/doc/python-numarray-1.3.3/release_notes/ANNOUNCE-1.3.~1.4.~
  E: python-numarray non-executable-script 
     /usr/lib/python2.4/site-packages/numarray/examples/convolve/benchmark.py 0644

Well, I found two other packages.  python-numeric (in core) has include files in
the main package.  python-imaging creates a -devel package, but it also has lots
of examples in the devel package as well.  I'm leaning toward no -devel package
since it just a few small text files.

Cleaned up the other errors and released -2.

Adding a "Provides: %{name}-devel = %{version}-%{release}" would sound like a 
good idea to me. 

Added the provides and re-pushed -2.  Ed - can you review/approve?

Hi Orion, heres the review notes:

needswork:
 - rpmbuild warns about files being list twice such as:

     warning: File listed twice: 
       /usr/lib/python2.4/site-packages/numarray/__init__.pyo

   so please take a closer look at

     %{python_sitelib}/numarray/
     %ghost %{python_sitelib}/numarray/*.pyo

   in the files section -- I don't know whether its a bug or 
   something that can be ignored or just my ignorance of the 
   %ghost macro...

good:
 - license looks OK and is included although one has to execute:

     $ python
     >>> import numarray
     >>> print numarray.__LICENSE__

   to read it (which seems OK since it appears to be what the 
   authors wanted and they went to some effort to have it that 
   way)

 - rpmlint reports warnings for the 16 *.h files but then the
   package does Provide: python-numarray-devel so someone could 
   easily split them off at a future date

 - specfile is easy to read and looks OK
 - names look OK
 - source matches upstream
 - builds nicely in mock on FC-4
 - Requires and BuildRequires look OK
 - dir ownership looks OK
 - code not content
 - no segfaults encountered

and I don't know what to say about the %ghost bit and the files-listed
-twice warning.  If it weren't so late right now I'd Google for some
examples and/or documentation.  But I need sleep...  ;-)

Get rid of the "file listed twice" issue like this:

Change:
%{python_sitelib}/numarray/
%ghost %{python_sitelib}/numarray/*.pyo

To:
%dir %{python_sitelib}/numarray
%{python_sitelib}/numarray/*.py
%{python_sitelib}/numarray/*.pyc
%ghost %{python_sitelib}/numarray/*.pyo

Some people would advocate including the .pyo files rather than ghosting them too.

Okay, looks like %ghost is the way to go.  -3 has been pushed.

Hi Orion, I just downloaded and built -3 in mock without any problems.  
Your %ghost approach gets rid of the listed-twice problem -- good!
And it might be easier to maintain if the syntax was something like:

  %dir %{python_sitelib}/numarray
  ...list the other dirs...
  %{python_sitelib}/numarray/*.[ps][yo]
  %{python_sitelib}/numarray/*.pyc
  %{python_sitelib}/numarray/*/*.[ps][yo]
  %{python_sitelib}/numarray/*/*.pyc
  %ghost %{python_sitelib}/numarray/*.pyo
  %ghost %{python_sitelib}/numarray/*/*.pyo

But you maintain it so its your choice...  ;-)

Approved!

Skimming the commit I noticed that this is an arch dependent package but uses 
%{python_sitelib}.  That will most likely fail on x86_64.  If that's the case, 
use %{python_sitearch} instead (see python spec template in 
fedora-rpmdevtools). 

Just discovered this.  Thanks.

Checked in and built.

Changed summary for tracking purposes.