[gentoo-dev] Re: Disabling auto-bumping of active Python version

[Jesus Rivero (Neurogeek)]

+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 <sping@g.o> 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