Proper categorization and metadata for Python rpms?

[Mike C. Fletcher]

I'm looking at how one goes about creating RPM distributions for Python 
packages (using distutils). The documentation doesn't give any 
recommendations regarding the proper specification of dependencies or 
provided features, so I am posting here with my current plans, in the 
hope that some Linux people will be kind enough to correct that 
understanding.

Here is my current plan:

    PyOpenGL is dependent on quite a few libraries (and one tool),
    Python 2.2.2, Numeric Python, Tkinter, OpenGL, GLU, GLUT (and SWIG
    1.3.13).

        I specify the libraries as "requires" options to the bdist_rpm
        command:

            'requires':'python,OpenGL,glut,tkinter,tk,Numeric'

        Not sure how to specify the requirement for SWIG (and
        particularly that version). Note that the only RPM'd version of
        Numeric seems to be v20 (we are sensitivie to that annoying
        shuffling of a structure introduced between v21 and v22, so we
        would like to be able to specify Numeric-22 or something like
        that (and then have an RPM available for it, of course)).

        Similarly, not sure what to specify regarding dependencies on
        source tarballs (e.g. for header files) or the like for
        building.  I'm assuming you can specify something in
        build-requires, but I'm not sure what.

    PyOpenGL also provides quite a number of facilities, which I would
    like the user to be able to specify separately, particularly as we
    may eventually break out the various components into multiple RPMs. 
    I'm particularly interested in what I should call these
    "capabilities" provided by the package.  Here's what I'm currently
    planning:

        'provides':'python-OpenGL,python-GLU,python-GLUT,python-GLE,tk-togl'

    That is, all of the items which are python-specific (i.e. python
    libraries) are given the python- prefix, while the tk component
    (togl) is given the tk- prefix (togl doesn't currently have a
    non-python RPM AFAICS). 

However, when I look at the few Python libraries I find with RPMs 
(Numeric, Tkinter, wxPython, pychecker), the capabilities that are 
declared are just "Numeric", "tkinter", "wxPython" and 'pychecker'.  Is 
this a general RPM policy?  Is there a mechanism for de-cluttering the 
namespace?

General guidance on how to properly build RPMs for Python packages would 
be helpful too (e.g. is it best to do so as root or as an unprivelidged 
user? Is there anything needed in the shell environment to ensure that 
the RPMs are generally usable?)

bdist_wininst is so much easier, really :) ,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/