[Numpy-discussion] RPMs out of date, have problems
Joe Harrington
jh at oobleck.astro.cornell.edu
Fri Jan 4 10:25:04 EST 2002
In the exchange below, my query is >>, Gerard's response is >, and my
present response to that is unquoted.
>>From: Gerard Vermeulen <gvermeul at labs.polycnrs-gre.fr>
>>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--
More information about the NumPy-Discussion
mailing list