Fun with Feisty and Python 2.5 3

Posted by timgoh
on Saturday, April 14

EDIT (May 18, 2007):

Ok I noticed from my awstats that a decent percentage of my traffic comes from looking for this problem, some through Google and others through a thread from the Ubuntu forums. I did not expect my quick hack to be used by so many others (honestly at the time I didn’t even know if it would work for me in the long term), but hey whatever works.

My original post was written as a “hey look what I found” and not as a “here’s how you fix this problem”, so I’m posting a much more succinct version. (The past two paragraphs don’t count!)

Who this fix is for: This fix is if you need python 2.4 as your default Python version in Feisty.

Those who familiar with Linux may have already tried symlinking /usr/bin/python to /usr/bin/python2.4, but get this error message:

ValueError: the symlink /usr/bin/python does not point to the python default version. it must be reset to point to python2.5

Here’s how to downgrade your default version in Feisty to Python 2.4 without those errors. Be very aware of my disclaimer at the end of the post before you follow any of this.

1. If you haven’t already, symlink /usr/bin/python to /usr/bin/python2.4

sudo ln -s /usr/bin/python2.4 /usr/bin/python

2. Edit your /usr/share/python/debian_defaults/ file

sudo vim /usr/share/python/debian_defaults

The initial few lines should read:

[DEFAULT]
# the default python version
default-version = python2.5

3. Change the third line to read:

default-version = python2.4

That’s all.

Once again, please read the disclaimer at the end of this post before you try this. I have been developing in Python and running Python apps on my system for a month with this fix, and have not encountered any problems yet.

Now, a favor to ask. If this works for you, please leave a comment saying it did. If it doesn’t, please leave a comment saying so with the appropriate error messages.

This way future people who are directed here can be more (or less) confident about this hack. Wouldn’t this post have been more valuable to you when you came if there were a bunch of affirmations and fixes for certain situations?

Call me a comment whore if you like, but comments here would benefit everyone who comes here looking for a solution. Or comment on the Ubuntu official forums thread .

Original post follows…

Previous Post:

(I would subtitle this “The journey is worth more than the destination”)

So Feisty comes with Python 2.5.

Now that’s not a problem right? Just symlink your /usr/bin/python2.4 and switch when necessary.

Except switching is far too excessive – “sudo apt-get upgrade” had dpkg crapping out on me saying that python was not symlinked to python2.5. Since my current projects are not 2.5-ready, I would have to swap back and forth a lot. This is particularly annoying since the problem package in my case, “update-manager-core”, does not require 2.5 to work.

I tried setting up update-alternatives to ease this a little:

sudo update-alternatives --install /usr/bin/python python /usr/bin/python2.4 2
sudo update-alternatives --install /usr/bin/python python /usr/bin/python2.5 1
sudo update-alternatives --config python

This method does not save that many keystrokes from manually symlinking as necessary, but it’s easier and has less room for error I suppose.

However, this does not work. update-alternatives will symlink /usr/bin/python to /etc/alternatives/python (which is symlinked to the appropriate python version in /usr/bin) , which will cause /usr/share/pycentral-data/pyversions.py to choke (it is hardcoded to check for a symlink in the /usr/bin directory1)

/usr/share/pycentral-data/pyversions.py lines 129-130:

if not _default_version in (debian_default, os.path.join('/usr/bin', debian_default)):
    raise ValueError, "the symlink /usr/bin/python does not point to the python default version. It must be reset to point to %s" % debian_default

While poking around here, I noticed that the default version is set in /usr/share/python/debian_defaults/

relevant snippets from /usr/share/pycentral-data/pyversions.py:

config.readfp(file('/usr/share/python/debian_defaults'))
_defaults = config
value = _defaults.get('DEFAULT', name)
### name == 'default-version' in this circumstance

So I merrily made my way to the debian_defaults file and set the default version to python2.4. Double-checked with Debian Python Policy to make sure I wasn’t doing anything catastrophic. The relevant details are in section 1.3.1, and from my understanding of it, the change I made is safe.

I verified this change against my original problem – dpkg throwing an error when upgrading/installing/removing “update-manager-core” with /usr/bin/python symlinked to /usr/bin/python2.4. Problem solved without having to switch the symlink to python2.5. So this change has fixed a bigger problem than I was originally trying to solve – I now cut down the amount of symlink switching instead of making switching more convenient!

This is a huge hack though. I wouldn’t recommend it. For one thing, my “python” package (like any default Feisty install) is for Python 2.5, which conflicts with my manual change to debian_defaults. I do intend to keep this change for now but revert the moment I notice any strange behavior.


1 That is a bug for some other time—surely that code needs to include the possibility of update-alternatives being used. It’s not like that’s some obscure corner case.

Comments

Leave a response

  1. Neil MayhewDecember 31, 2007 @ 11:50 PM
    A less drastic approach would be to leave the system default set at 2.5, and arrange for scripts that need 2.4 to run with 2.4. There are various ways of accomplishing this. The crudest is to put #!/usr/bin/python2.4 at the top of those scripts. Another is to do it on a per-user basis, with ~/bin early in the PATH and ~/bin/python a symlink to /usr/bin/python2.4. For my project, I have left #!/usr/bin/env python as the shebang line, but created a shell script called "python" in the project's scripts directory, which contains: #!/bin/sh exec /usr/bin/python2.4 "$@" This script is invoked by the shebang line in the .py files, and then invokes the correct version of python to do the work. When I've upgraded my python sources to work with 2.5, I can either remove this script, or modify the exec line to be some other version of python. I think this gives maximum flexibility.
  2. TimDecember 31, 2007 @ 11:50 PM
    Hi Neil, That sounds like an interesting approach -- will give it a whirl. Thanks for sharing!
  3. Samori GorseJune 13, 2008 @ 02:44 PM

    I add the same problem like 10 minutes ago, I assume that this pyversions is dedicated to debian/ubuntu so I just added :

    if not _default_version in (debian_default, os.path.join(’/usr/bin’, debian_default), ’/etc/alternatives/python’,):

    And it works, even is update-alternatives is not installed, that shouldn’t matter.

    Regards

Comment