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
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.
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
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.
