[BioPython] Installing Python2.1.1 for biopython

[Alex Lancaster]

>>>>> "KS" == KELLEY SCOTT T <kelleys@ucsu.colorado.edu> writes:

KS> I'm trying to install python 2.1 using the rpm approach
KS> (python2-2.1.1-3.i386.rpm) and I'm coming across some errors.
KS> Bascially it says I do not have some dependencies needed by rpm.

KS> error: failed dependencies: libcrypto.so.1 is needed by
KS> python2-2.1.1-3 libexpat.so.0 is needed by python2-2.1.1-3
KS> libssl.so.1 is needed by python2-2.1.1-3

KS> Apparently I am not the only one running into this issue. Have any
KS> of you run into these problems and perhaps have a solution?

KS> Thanks for any help you can pass my way.

You probably have a distro-version problem.  If you are running Red
Hat, then RPMs are only reliably compatible only within a specific
version.  i.e. RPMs that are build on Red Hat 7.n will have extra (or
new) dependendices (normally shared-libraries) that don't exist for
Red Hat 7.(n-1).  You basically have three choices:

1. Upgrade your entire system to the distro for which you got the RPM
   for.

2. Get the SRPMS (the "source" RPM), install it as root, and rebuild
   it: rpm -ba <spec-file>, to get a new RPM, then install it.

3. Install from source.

I think Red Hat have a policy that most shared libraraies won't be
upgraded a major version number, within a given distro series
(e.g. 6.x or 7.x) to avoid just such a problem, which suggests to me
that the RPM is not from Red Hat itself (or is from a more advanced
series) or you are running a different distro from the one the RPM was
built for.

For example on Red Hat 7.2 (the recently released "enigma" release,
which I just installed yesterday), I have the following:

$ rpm -q python2
python-2.1.1-2

and it requires libcrypto.so.2, libexpat.so.0, libssl.so.2 (which are
part of packages such openssl etc.)

The moral of the story, always install an RPM that matches your
distribution as closely as possible.  There are no truly "generic"
RPMs.

Just FYI: right now, the reason that Python comes as separate
"python2" package, in addition to the standard "python" package (which
is normally Python 1.5.2), is that most distributions have system
scripts and/or third party packages that haven't been ported to Python
2.x, and so would break if Python version 2.x become the "default"
Python (the same was true when Perl went from 4.x -> 5.x).  Once
Python 2 becomes more the "default" Python on most distros (which I
expect within the next 6 months or so), then the need to have 2
versions side-side by side will hopefully go away.

Alex
-- 
    Alex Lancaster * alexl@users.sourceforge.net * SourceForge Developer