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
