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

[Cliff Wells]

On Mon, 2003-10-06 at 19:00, Skip Montanaro wrote:
>     >> 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.  
> 
>     Cliff> IMO, the *best* solution would be for Redhat and other vendors to
>     Cliff> keep a "system" version of Python separate for their own needs,
>     Cliff> e.g /usr/bin/python-rh could link to their 2.2 install with all
>     Cliff> of its modules.  
> 
> I think this is one of those "slippery slopes".  Taken to its logical
> conclusion, vendors would have to provide "system" versions of bash, Perl,
> GCC, glibc, ... just to ensure that users could overwrite vendor-provided
> tools. 

And taking things to their logical conclusion is often a slippery slope
of its own.  Programmers have a way of thinking that finds pure
consistency more appealing than practical application.  While I don't
entirely disagree you that there is a danger, I would suggest that when
a commonly used package (such as Python) is so central to the operation
of vendor supplied packages that upgrading it is nearly impossible, that
the vendor should keep their own copy.  Do perl, bash, et al fall into
this category?  I don't know, but I've never had a problem upgrading
them, while upgrading Python on Redhat is a royal pain.  This suggests
to me that perhaps Redhat should maintain their own installation of
Python with a different name.

>  The simpler solution is to allow users to install their own copies
> of various tools in non-system directories (/usr/local, /sw, ~/local, ...).

But the downside of this is when a user installs some package, say
boa-constructor and wants it to use the user-supplied version of Python,
then they must edit the shebang line in every relevant file.

To be certain, probably the real problem is the packaging system, which
is unable to provide enough information to make upgrading a reasonable
task.  If rpm were able to give a list of packages that relied on
Python, then it would be a straightforward, if tedious, process for the
user to obtain the source rpms for said packages and rebuild them
against a newer version of Python.


Cliff

-- 
Someone shot nostalgia in the back, someone shot our innocence
                                                     -Bauhaus