Python 2.2 on Red Hat

[David Ripton]

"Russell Blau" <russblau at hotmail.com> wrote in message news:<3016rjF2pvp6kU1 at uni-berlin.de>...
> "David Ripton" <dripton at ripton.net> wrote in message
> news:9b6f95cb.0411170639.6e5c45fc at posting.google.com...
> > Andy Jacobs <oct at redcatmedia.net> wrote in message
> news:<BDC02405.3068%oct at redcatmedia.net>...
> 
> > So you need to put a newer Python somewhere else.
> >
> > My advice is to install modern Python (like 2.3.4), from source (it's
> > easy: standard ./configure; make; su; make install), under /usr/local.
> 
> No, you need to "make altinstall", not "make install", to prevent having
> python2.3 overwrite the system's built-in python symlink.

No.  "make altinstall" is only needed if you want to put two versions
of Python in the same basedir.  I suggested leaving /usr alone and
installing the new local Python in /usr/local.  When you do that
there's no namespace clash, so no need to use altinstall.

Yes, if you want to put two Pythons in the same basedir, then
altinstall is handy.  But not as bulletproof as using separate
basedirs.  Try installing debug and non-debug builds of the same
Python version in the same basedir using altinstall to see what I
mean.

Robustness aside, letting the package manager handle /usr and putting
your local changes in /usr/local is The Right Thing To Do.  RPM can't
scribble over changes not in its turf.  The Filesystem Hierarchy
Standard is fundamentally sane.