+1 I totally agree with the conclusion. I believe that choice, "select the active version of Python", should not be implied by us, but taken by the user even if he explicitly asked for a new version to be installed.
I've been in this situation before, and just because I wanted to try some new cool features, sometimes I ended up with a semi broken system just because I wouldn't take extra care with it. Plus I think users are going to miss that feature much. Best regards, Jesus On 11/14/10, Sebastian Pipping <sp...@gentoo.org> wrote: > Hello, > > thanks for your interest. This thread is not about Python 3.x in > particular, in case you wonder. > > > In this mail > ============ > - Typical GCC update (for comparison) > - Python 2.7 update simulation (and how it fails) > - The scenario > - What happens > - How it happens > - Conclusion > > > Typical GCC update > ================== > Before we look at Python, let's have a look at how it works with GCC: > > When a new version of GCC appears in Gentoo, it is installed into > a new slot. To activate the new version, you run gcc-config. > In the meantime your system is in working state and continues to > use the old version of GCC. > > > Python 2.7 update simulation > ============================ > > The scenario > ------------ > With Python it's very different. Let's assume a system with Python 2.6 > as the only Python around. Now we would like to run this command: > > # sudo emerge dev-lang/python:2.7 dev-python/pyinotify > > Assume that dev-lang/python:2.7 is unmasked already. > The resulting system state now depends on these two factors: > > - Has pyinotify been installed to the system before our invocation of > emerge? Depending on that, pyinotify may be installed first, or > python 2.7 may. Let's assume pyinotify comes last. The difference > is marginal. > > - Were we using USE_PYTHON in /etc/make.conf (e.g. USE_PYTHON="2.6") > or not? I'll assume USE_PYTHON is not set manually and implied > during installation. The last three devs I spoke to had not heard > of variable USE_PYTHON, so that assumption may work. > > > What happens > ------------ > Steps taken by emerge: > - Python 2.7 installed > - Python 2.7 is made the active version of Python automatically > - pyinotify is installed for Python ABI 2.7 (neither 2.6 nor both) > > Resulting system state: > - Python 2.7 now is the main active version of Python > - All Python packages except pyinotify are installed for Python ABI 2.6 > - pyinotify is the only package installed for Python ABI 2.7 > - before running python-updater larger parts of the system may be > unusable > > > How it happens > -------------- > All dev-lang/python ebuilds run a Bash function called > "eselect_python_update" at the beginning pkg_postinst stage. > Former function wraps a call to > > eselect python update ${eselect_python_options} > > > Conclusion > ========== > When you update GCC your system stays at a healthy state. > You trigger the switch of active versions. > > With Python, when you install a newer version if gets activated, leaving > your system in broken state. An update of Python always involves > running python-updater. If the user/admin has to run that anyway, why > should we take the call to eselect python off his shoulders, especially > we break the system doing so? > > So I plan to remove the call to eselect_python_update from all Python > ebuilds in two weeks from now. Besides Arfrever everybody I spoke to on > this topic so far agreed to this approach. The two weeks window are to > give people room to think and discuss about it. > > Please try to keep this thread as low-heat as possible. > Thanks for reading. > > > > Sebastian > > -- Sent from my mobile device Jesus Rivero Gentoo Python Team