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

[Joe Harrington]

> I *never* build into /usr or /usr/local.

Good!  You should leave /usr for your package manager to deal with.
However, you should *release* software to install there, which you can
with RPM without having to build it in /usr.  /usr/local is yours to
play with.  The only thing in mine is IDL.  (...which is why I'd like
to delete it!)

> I suppose
> what was bothering people was having to use --prefix because the default
> will not work because my Python is not in some standard place (said
> standard place seeming to me to be a mythical location given how I see
> people actually working).

There was no documentation anywhere in the download area suggesting
the use of --prefix.  Even if there were, RPMs get collected and put
in archives (rpmfind.net) without any other associated docs.  They
should always install into the system following the Linux file system
standards.  Nobody expects to have to configure an RPM.  They're just
supposed to work, and the vast majority just do.

> There are lots of people like me
> that have multiple pythons around with other stuff added in.

There are lots if *developers* like you.  The current group of Numpy
users is demographically distinct from the future user base, if Numpy
becomes a player for numerical work in science and engineering.  We
will have many users who have never written a line of C or C++ or
FORTRAN and who will run screaming at the mention of the word "tar".
We will have high school teachers and students.  We will have lots of
people who have zero time and zero tolerance for learning unrelated
topics like system administration or software tweaking.  If we don't
care about them, they won't use our software.

> I continue to be less than impressed by RPMs. Every time I try one I get
> version conflicts with other software.

I understand your frustration with the bad RPMs, but it's not the
fault of RPM, it's the fault of either the package developer or the
person installing the package.  If the package developer links against
a library that is itself under rapid development, there is a problem
waiting to happen.  It's worse if that library is included in some or
all distributions.  The simple solution is to statically link that
library, or rename it and include it in the package.  If the user has
an out-of-date system, it's also trouble.

If we build against the C library and python that are in the OS
releases, we're in good shape.  I don't think we need to bend over
backwards to provide RPMs for people who install their own Python,
unless a new version of Numeric requires use of an updated Python RPM.
Very few (maybe 0.5%?) "mass-market" users will install their own
Python.  The experts who do can handle a tarball install, or one will
build an RPM and distribute it if it's a particularly important
release.

The conflict problems pale in comparison to the problems with manually
building all packages you want to install, particularly if you don't
know how to fix makefile problems or don't have a compiler.  If you're
only installing a few packages, it's not that big a deal.  If you're
installing 90, it's a month's work by hand or a day with RPM, if you
don't know the install procedure for the software beforehand.  See
ftp://oobleck.astro.cornell.edu/pub/clues.tar.gz for my attempt to
tame this problem.  As you can see from the dates of the files
therein, I abandonned maintaining each package page as it came out
under RPM.  It was just impossible to keep up.  It's trivial under
RPM.  Plus, I can uninstall!  What matters is what the general users
want, and they have spoken loudly in favor of package managers.

Konrad writes:
> RedHat
> is rather conservative among the Linux distributors, but that is also
> the reason for still using Python 1.5 in their latest versions.

/usr/bin/python2.1 exists under 7.2, and claims in its startup that it
existed in 7.1.  You get 1.5.2 if you just type "python", but you get
2.1.1 if you type "python2.1".  alias python python2.1...

--jh--