bruce wrote:
>
i'min a situation where i might need to upgrade python. i have the current
version of python for FC3. i might need to have the version for FC4. i built
the version that's on FC4 from the python source RPM.
In principle this is a good idea, since you're aiming to manage your
installed software correctly, allowing the package management system to
permit uninstalls and the dependency management system to control
dependencies. (In fact, I go as far as to make Debian/Ubuntu packages
for virtually all Python packages I obtain independently of the
system's package management utilities, just so that I can then use such
utilities to install the software "properly".)
however, when i simply try to install the resulting RPM, the app gives me
dependency issues from apps that are dependent on the previous/current
version of python.
This is one of the main issues with upgrading things upon which large
numbers of other components or applications are dependent. Really, in
order to preserve those applications, there would need to be an upgrade
path for them (and their libraries) based on the newer version of
Python, and I imagine that a lot of dependency management systems might
refuse to offer a bulk upgrade, especially if some of the applications
or libraries weren't available in an updated form.
i'm trying to figure out if there's a 'best' way to proceed.
do i simply do the install, and force it to overwrite the current version of
python?
No: you'll probably break various important applications. As you've
seen, you'd need to offer yum all the potentially upgradable packages,
and although various "distribution upgrade" operations are often
possible, it's a major step just to try something out.
is there a way to point 'yum' at my new python RPM, and let yum take care of
dealing with any dependcy issues? and how would yum handle weird dependency
issues with RPMs that don't exist.. does yum have the ability to actually
build required apps from source?
I don't really recall many details about yum, since its introduction
came at the end of my Red Hat user experience, but yum is surely a
dependency manager that itself doesn't build packages, although I can
imagine it having features that could ask rpm (the package manager) to
do so. As I note above, to get yum to understand the missing packages,
you'd need to tell it about the Fedora Core 4 repository, but this is
probably only done safely via a "distribution upgrade" that would be
quite drastic.
comments/thoughts/etc...
[...]
ps. the reason for this is that i'm looking at some of the newer
functionality in the 2.4 version of python over the 2.3
If I were in your position, I'd either do a "make altinstall" of Python
2.4 which should put Python 2.4 (as python2.4) alongside Python 2.3 (as
python, python2.3) in /usr/bin (where you would give /usr as the
installation prefix when configuring Python). Otherwise, I'd choose a
different installation prefix (by default, Python installs into
/usr/local) and then change your environment variables for affected
users or programs to use Python from this new location in preference to
the system installation of Python.
In other words, you probably want to install an isolated version of
Python for the special purpose of using newer functionality in your own
applications. Anything else may be a lot of work, disruption and a lot
more besides.
Paul
