FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 11-14-2010, 03:28 PM
Sebastian Pipping
 
Default Disabling auto-bumping of active Python version

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
 
Old 11-14-2010, 05:04 PM
"Jesus Rivero (Neurogeek)"
 
Default Disabling auto-bumping of active Python version

+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@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
 
Old 11-14-2010, 08:42 PM
Florian Philipp
 
Default Disabling auto-bumping of active Python version

Am 14.11.2010 17:28, schrieb Sebastian Pipping:
>
> 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.
[...]

Is there a chance to do the same for perl and perl-cleaner?

I understand perl is not slotted at the moment and there are probably
good technical reasons for not doing so but I still wanted to ask.

There are similar issues with ocaml and ocaml-rebuild.sh.

Best regards,
Florian Philipp
 
Old 11-15-2010, 01:37 PM
Sebastian Pipping
 
Default Disabling auto-bumping of active Python version

On 11/14/10 22:42, Florian Philipp wrote:
> Is there a chance to do the same for perl and perl-cleaner?
>
> I understand perl is not slotted at the moment and there are probably
> good technical reasons for not doing so but I still wanted to ask.

I'm not sure if the Perl team is watching this thread.
Maybe ask on gentoo-perl directly.

http://www.gentoo.org/main/en/lists.xml


> There are similar issues with ocaml and ocaml-rebuild.sh.

Maybe try contacting ml@g.o on that one. I don't see any Ocaml project
pages or mailing lists in Gentoo.



Sebastian
 
Old 11-15-2010, 09:02 PM
Alexis Ballier
 
Default Disabling auto-bumping of active Python version

On Monday 15 November 2010 11:37:08 Sebastian Pipping wrote:
> On 11/14/10 22:42, Florian Philipp wrote:
> > Is there a chance to do the same for perl and perl-cleaner?
> >
> > I understand perl is not slotted at the moment and there are probably
> > good technical reasons for not doing so but I still wanted to ask.
>
> I'm not sure if the Perl team is watching this thread.
> Maybe ask on gentoo-perl directly.
>
> http://www.gentoo.org/main/en/lists.xml
>
> > There are similar issues with ocaml and ocaml-rebuild.sh.
>
> Maybe try contacting ml@g.o on that one. I don't see any Ocaml project
> pages or mailing lists in Gentoo.


Since none are slotted, I don't understand what outcome you expect by
contacting the maintainers.
At best, perl-cleaner and ocaml-rebuild.sh shall be merged into portage in a
preserve-libs like manner.

A.
 
Old 11-16-2010, 02:22 AM
Zac Medico
 
Default Disabling auto-bumping of active Python version

On 11/15/2010 02:02 PM, Alexis Ballier wrote:
> Since none are slotted, I don't understand what outcome you expect by
> contacting the maintainers.
> At best, perl-cleaner and ocaml-rebuild.sh shall be merged into portage in a
> preserve-libs like manner.

In case some aren't aware, I'll mention that abi-slot dependencies
(if/when implemented) can potentially serve as a generic solution that
covers all such un-slotted cases (as discussed in bug #192319 [1]). For
slotted packages, the rebuild logic will be slightly different, but it
will be nice to devise a generic solution for those too.

[1] https://bugs.gentoo.org/show_bug.cgi?id=192319
--
Thanks,
Zac
 
Old 11-27-2010, 12:00 PM
Sebastian Pipping
 
Default Disabling auto-bumping of active Python version

On 11/14/10 17:28, Sebastian Pipping wrote:
> So I plan to remove the call to eselect_python_update from all Python
> ebuilds in two weeks from now.

Now fixed in both the main tree as well as the Python overlay.
Please let me know in case I broke anything.

Best,



Sebastian
 
Old 11-28-2010, 05:04 PM
Arfrever Frehtes Taifersar Arahesis
 
Default Disabling auto-bumping of active Python version

2010-11-27 14:00:28 Sebastian Pipping napisał(a):
> On 11/14/10 17:28, Sebastian Pipping wrote:
> > So I plan to remove the call to eselect_python_update from all Python
> > ebuilds in two weeks from now.
>
> Now fixed in both the main tree as well as the Python overlay.
> Please let me know in case I broke anything.

You probably broke generation of stages .
(I have restored a minimal version of eselect_python_update() in python overlay.)

--
Arfrever Frehtes Taifersar Arahesis
 
Old 11-29-2010, 06:39 AM
Sebastian Pipping
 
Default Disabling auto-bumping of active Python version

On 11/28/10 19:04, Arfrever Frehtes Taifersar Arahesis wrote:
> You probably broke generation of stages .
> (I have restored a minimal version of eselect_python_update() in python overlay.)

Could you elaborate on that, please? How did I break stages? Which
stages? Future stage tarballs?



Sebastian
 
Old 11-29-2010, 07:35 AM
Arfrever Frehtes Taifersar Arahesis
 
Default Disabling auto-bumping of active Python version

2010-11-29 08:39:46 Sebastian Pipping napisał(a):
> On 11/28/10 19:04, Arfrever Frehtes Taifersar Arahesis wrote:
> > You probably broke generation of stages .
> > (I have restored a minimal version of eselect_python_update() in python overlay.)
>
> Could you elaborate on that, please? How did I break stages? Which
> stages? Future stage tarballs?

There will probably be no active version of Python set.

--
Arfrever Frehtes Taifersar Arahesis
 

Thread Tools




All times are GMT. The time now is 02:50 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org