Bug 47597 – Upgrading python-2.2 to python-2.3 breaks portage

• Product: Gentoo Linux
• Status: RESOLVED TEST-REQUEST

[Description Stuart Herbert (RETIRED) 2004-04-12 04:49:52 UTC]

Upgrading from portage-2.0.48 to 2.0.50-r5 was even more entertaining.  This automatically upgrades python from 2.2 to 2.3.  Now, as I understand it, python-2.3 can't see all the installed modules straight off.  There's a helpful python-updater script provided to fix this.  Problem is, this updater relies on portage ... which relies on the modules that python 2.3 cannot yet see.  So the python-updater script doesn't work.  Ho hum.  

I'm sure I saw a message that python-2.2 is still installed - and is used by older versions of Portage.  I checked.  Python-2.2 is still installed, but the version of Portage-2.0.48 on my machines use /usr/bin/python - which is python-2.3 thanks to the upgrade.

This, of course, assumes that the user has a large enough scroll-back buffer to see the ebuild's warnings about needing to run the python-updater script.  If they don't ... well, they're not going to know what to do.

The symptom that the user will see will be the error message 'ImportError: No module named output' whenever they try to do anything with 'emerge'.

The manual work-around for this seems to be:
1) edit `which portageq`, and make it use /usr/bin/python2.2 rather than /usr/bin/python
2) edit `which emerge`, and make it use /usr/bin/python2.2, rather than /usr/bin/python
3) run the python-updater script
4) run etc-update afterwards
5) upgrade to portage-2.0.50-r5

It's also worth pointing out that etc-update and env-update are also broken by the botched python upgrade.  etc-update relies on portageq (reasonable requirement ;-), which doesn't work without the manual work-around I've included above.

Best regards,
Stu

[Comment 1 Bryan Østergaard (RETIRED) 2004-04-12 05:27:04 UTC]

portage-2.0.49-r16+ works with both python-2.3 and python-2.2. So you need to upgrade portage to a newer version before upgrading python. We used to have a check on the portage version in the python ebuild, but this check created a nasty circular dependency between portage and python when installing.

I'd love a good solution to this problem but the portage and python teams haven't been able to come up with something better than what we have now.

[Comment 2 Stuart Herbert (RETIRED) 2004-04-12 06:35:47 UTC]

Okay, how about putting a blocker in python-2.3, so that you can't upgrade unless you're running one of the safe 2.0.49 releases of Portage?  It'd be annoying, but not as annoying as the current situation.

Or, provide a python-config tool, and force the user to switch from python-2.2 to python-2.3 manually by using the tool?  Again, annoying, but not the end of the world.

I don't know python too well, but surely there's a way to have new versions of python automatically pick up classes installed with older versions?  That's what is at the heart of the problem.  Is this a python design problem, or just down to the way we lay out python once installed?

Best regards,
Stu

[Comment 3 Bryan Østergaard (RETIRED) 2004-04-29 23:02:29 UTC]

Liquidx committed a python-2.3.3.ebuild a while ago that's supposed to fix this problem. We still need some testing of this afaik. I'll see if I have a box still running python-2.2 and portage <2.0.49-r16.