Re: [Numpy-discussion] RPMs out of date, have problems

[Joe H. <jh...@oo...>]

In the exchange below, my query is >>, Gerard's response is >, and my
present response to that is unquoted.

>>From: Gerard Vermeulen <gve...@la...>
>>Subject: Re: [Numpy-discussion] RPMs out of date, have problems
>>Date: Fri, 4 Jan 2002 09:44:21 +0100

>> Could you check that it produces an RPM with files that go in
>> /usr/lib/python2.1     rather than /pcmdi/dubois/linux/lib/python2.1 and
>> /usr/include/python2.1 rather than /pcmdi/dubois/linux/include/python2.1?

>Yes, mine go into /usr/lib/python2.1

>> Paul D. isn't sure why /pcmdi is being created.  It's probably that
>> way on his machine and he doesn't know how to tell distutils to use a
>> different default prefix.  Neither do I.  That is the issue.  Do you?

>Well, the paths are figured out in /usr/lib/python2.1/distutils/sysconfig.py,
>using sys.prefix or sys.exec_prefix.

>So, I think that Paul's python has been build with
>./configure --prefix=/pcmdi/dubois/linux
>and that it still lives there, or has been moved to /usr afterwards.

>Or that it resides on an NFS mounted volume???
>Or some python startup file that messes sys.(exec_)prefix.

Ok, Paul, Konrad, is this what you need?

>Anyhow, I think that with respect to binary packages
>Windows has the edge over Linux (I know from experience,
>because I am author of a Python wrapper to Qwt - a Qt library
>allowing to do interactive plotting and it is SO easy to
>produce a Windows).

>Every combination of Distro-Version-Python-Version would
>require its own binary RPM.

If you consider Microsoft Windows one OS, Red Hat Linux another,
Debian GNU/Linux a third, and so on, the distinction goes away.  The
fact that Microsoft has a monopoly is definitely convenient to
producers.  However, as users, we lose and shouldn't support it.

>(A) IMHO, it is better to add a README.DIY.RPM:
>(I am going through the steps based on Numeric-20.2.1)
>(1) unpack Numeric-20.2.1.tar.gz (or whatever)
>(2) cd Numeric-20.2.1
>(2) python setup.py bdist_rpm
>(3) cd dist
>(4) rpm -Uvh Numeric-20.2.1-1.i?86.rpm (as root, i?86 could be another
>architecture)

>But it is not so easy to build the extension packages (FFT & friends) like 
>this, without knowledge of RPM. I could try to hack setup.py to make it 
>compatible with RPM (means making 1 big package without subpackages)

>(B) The other possibility is to include a generic python-numeric.spec file
>(you build an RPM with rpm -ba python-numeric.spec). I can adapt mine.

>Gerard

>PS: do you have a RPM based Linux, yourself?

Yes, I run Red Hat.  So do the vast majority of US astronomers I have
spoken to.  I understand that SuSE is equally popular in Europe.  A
few other dists just copy one of them and add a few packages, and so
don't need separate RPMs of their own.  If we configure RPMs with the
version of python included in these dists, we're not talking about a
large number of packages, after all, to get 98% of the users or
better.  I think you are onto a solution:

We build RPMs (and .deb files for Debian, if we think there are enough
Debian users to make it worthwhile, and the same for Solaris if it
uses a different package manager) for the current release of each
popular distribution, with that release's python.  That's maybe 4
binary packages per Numeric release (Red Hat, SuSE, Debian, Solaris).
We also make a source RPM and distribute with it instructions for
building a new binary RPM with appropriately-named version ID (e.g.,
python-numeric-20.4py2.2glibc6-1).  We solicit users of unsupported
combinations of OS and Python version to contribute those RPMs along
with a simple ASCII form specifying what kind of system made it,
contact info, etc.  I predict we will not get a huge number of such
submissions from outside this list, as the vast majority of Numeric
users who upgrade their Python when a new Python release comes out (as
opposed to a new OS release) are developers who don't care about the
RPM anyway.

The ultimate solution is to get this thing incorporated into the
python core.

--jh--