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.

Advertisements

Cliff Wells <> wrote in message news:<>...
>
> 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.

With "complete" Red Hat installations weighing in at 4GB, I think Red
Hat could easily slip their own installation of Python in there
without anyone noticing.
> 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.

I don't agree with this, but then by installing from the source
distribution into /usr/local and by changing my PATH, I'm effectively
maintaining Red Hat's private Python installation for them.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!