Python 2.3.2 RPM's for Redhat 8.0 or Python source RPM and upgrade procedure?

[Skip Montanaro]

    Scott> Upgrading seems to ALWAYS be painful with these scripting
    Scott> languages.  Perl is no better.  I'd like to see Python beat Perl
    Scott> out in this arena (some friendly competition, huh? Where the end
    Scott> user benefits! :-) I'm running RedHat so their dependency on
    Scott> Python is a mixed blessing also.

    Scott> We, end users who are just getting into Python, look at this as
    Scott> something that should be "seamless" when in actuality it's a
    Scott> major change to upgrade a programming language environment that
    Scott> you have lots of dependencies around.  This change should be
    Scott> properly orchestrated and tested and it's probably a bit naive to
    Scott> expect it to be seamless like a simple one-off.

The problem is, there are lots of dependencies we (the people twisting the
knobs on the Python distribution) really can't control.  On my Mac I have
four different versions of Python: /usr/bin/python comes from Apple.
/sw/bin/python comes from fink.  /usr/local/bin/python and
~/local/bin/python are my doing.  I have no trouble with any of this for a
simple reason: I have my path jiggered to see ~/local/bin before anything
else, so I never run the versions Apple or fink installed, and I don't mess
with their stuff.  On the rare occasions where I explicitly want to run one
of the other versions, I just use a full path.  I think that's the best way
to do it on a Red Hat system as well (that's what I do on Mandrake, a Red
Hat derivative that seems to have eschewed Python for Perl).  It wastes a
little disk space but is much less likely to create heartburn for Red Hat's
tools or worse, leave you with a system on which you can't perform routine
administrative tasks or update.

Similarly, on many systems you can choose a vendor provided X (where X might
be a C compiler, database library or jukebox application).  If you want to
use a different version of those tools, you'd probably install them
somewhere different instead of overwriting the versions the vendor provides.
Replacing /usr/lib/libdb* with a later version of Sleepycat's library is a
sure-fire way to break your system in odd ways.  Scripting languages are no
different in this regard.  Wipe out what the vendor delivered at your own
peril.

Skip