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.
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.
Someone shot nostalgia in the back, someone shot our innocence