|
Matt Hoskins
matt at nipltd.com
Fri Jul 29 03:17:39 EDT 2005
> > The reason you can't easily change to another python on the system is > > because your version of Red Hat absolutely relies on the version of > > python that came with it, hence the limitation. There are other > > platforms that don't install or depend on python by default, so you can > > choose to install whatever version you wish. > > Python does support multiple installed versions, hence python and > python2 binaries. The python 2.x binary installed from source on a clean system will get named with its version number and then hard linked to a binary called "python" (often in /usr/local/bin). It's Red Hat's choice on that particular version of their OS to package python 2.x such that the binary is called python2 because for that platform the primary version of python is the old 1.x series. They could have called it "python-the-next-generation" if they wanted and still had their own packaged applications work using it. > > > > That's because it's meant to work with the *system-wide* version of > > python, which is customarily a link. On my system: > > > > /usr/bin/python -> python2.3 > > Mailman works fine w/ /usr/bin/python hard-linked to python1.5, yet > Mailman uses v2.2 solely and without problems. Mailman is not using the system-wide default version of python if it's using python v2.2 on a system where the pathed binary of "python" is 1.5 - perhaps mailman's configure script hunts around for alternatively named python binary files, who could say. The original point still stands that mod_python, unless told otherwise, picks up the system-wide default version of python - i.e the binary that's pathed as "python". > > install mod_perl with a new version of perl. Unfortunately, you don't > > have the option of setting the link to a new binary because some RH 7.3 > > components will break. > > v1.5 is really only necessary for yum, but if you know multi-server > (linux) administration you know you need yum. You mean a multi-server rpm-based linux system. If you look at the yum project page you'll see: yum 2.3.X - DEVELOPMENT RELEASE, requires repomd repositories: 2.3.4 latest yum 2.2.X - for python 2.2+ and rpm 4.1.1+ systems, requires repomd repositories: 2.2.2 latest yum 2.0.X - for python 2.1+ and rpm 4.1.1-4.3.1 systems: 2.0.8 latest yum 1.0.X - for python 1.5.2+ and rpm 4.0.4 systems: 1.0.3 latest - considered obsolete Looks like yum 1.0.X for python 1.5.2+ is considered by the authors as obselete. Later versions of yum seem to use (and probably require) python 2.x > > But for how long? RH 7.3 has been unsupported for quite a while. > > Unsupported by who, Redhat? Sure. There are other support avenues > however. That still doesn't negate the original point that Redhat themselves have denoted 7.3 as having reached its end of life and is out of support. > remain in operation for years at the same version level. Patching is > important of course, but major system overhaul is rarely necessary > unless upgrading the hardware. Did you know that Redhat 7.3 and Redhat > Enterprise Linix 2.1 are very similar in kernel and package versions. > Redhat EL 2.1 is still supported by Redhat. Redhat EL 3.0 is not that > much more different from RHEL 2.1. "Not that much more different". The mk-1 miata is very similar to the mk-2.5 miata - same name, 4 wheels, fuel injected engine, gear stick - under the hood tho' they're very different. In the computer world where precision is key small differences can have big impacts, likewise in a number of other fields. Given that mod_python is free software produced by volunteers and that this list has people voluntary giving up their time to try help then your attitude, Jim, comes across as overly and unnecessarily abrasive/confrontational and unappreciative. I'm actually amazed at how helpful some of the list members are when faced with unnecessarily thorny complaints made to the list. If you were to use a more recent linux OS you'd probably find that mod_python comes pre-packaged for it. It sounds like mod_python will work on the old version of RH that you're running, it just needs a little more care and fiddling in the installation. The mod_python authors don't (and shouldn't be expected to) have every OS and OS version stretching back to the dawn of time, along with package combination and insallation customizations out there - hence the installation may occasionally not be seamless on some of the rarer system combinations. Anyhow kudos to those on the list that are helpful, particularly Graham. I'm not disappointed with mod_python - it works very well, and I've deployed applications successfully which make use of mod_python on various win32, linux and solaris systems with minimal fuss. Matt Hoskins
|