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