1 |
Hello, |
2 |
|
3 |
thanks for your interest. This thread is not about Python 3.x in |
4 |
particular, in case you wonder. |
5 |
|
6 |
|
7 |
In this mail |
8 |
============ |
9 |
- Typical GCC update (for comparison) |
10 |
- Python 2.7 update simulation (and how it fails) |
11 |
- The scenario |
12 |
- What happens |
13 |
- How it happens |
14 |
- Conclusion |
15 |
|
16 |
|
17 |
Typical GCC update |
18 |
================== |
19 |
Before we look at Python, let's have a look at how it works with GCC: |
20 |
|
21 |
When a new version of GCC appears in Gentoo, it is installed into |
22 |
a new slot. To activate the new version, you run gcc-config. |
23 |
In the meantime your system is in working state and continues to |
24 |
use the old version of GCC. |
25 |
|
26 |
|
27 |
Python 2.7 update simulation |
28 |
============================ |
29 |
|
30 |
The scenario |
31 |
------------ |
32 |
With Python it's very different. Let's assume a system with Python 2.6 |
33 |
as the only Python around. Now we would like to run this command: |
34 |
|
35 |
# sudo emerge dev-lang/python:2.7 dev-python/pyinotify |
36 |
|
37 |
Assume that dev-lang/python:2.7 is unmasked already. |
38 |
The resulting system state now depends on these two factors: |
39 |
|
40 |
- Has pyinotify been installed to the system before our invocation of |
41 |
emerge? Depending on that, pyinotify may be installed first, or |
42 |
python 2.7 may. Let's assume pyinotify comes last. The difference |
43 |
is marginal. |
44 |
|
45 |
- Were we using USE_PYTHON in /etc/make.conf (e.g. USE_PYTHON="2.6") |
46 |
or not? I'll assume USE_PYTHON is not set manually and implied |
47 |
during installation. The last three devs I spoke to had not heard |
48 |
of variable USE_PYTHON, so that assumption may work. |
49 |
|
50 |
|
51 |
What happens |
52 |
------------ |
53 |
Steps taken by emerge: |
54 |
- Python 2.7 installed |
55 |
- Python 2.7 is made the active version of Python automatically |
56 |
- pyinotify is installed for Python ABI 2.7 (neither 2.6 nor both) |
57 |
|
58 |
Resulting system state: |
59 |
- Python 2.7 now is the main active version of Python |
60 |
- All Python packages except pyinotify are installed for Python ABI 2.6 |
61 |
- pyinotify is the only package installed for Python ABI 2.7 |
62 |
- before running python-updater larger parts of the system may be |
63 |
unusable |
64 |
|
65 |
|
66 |
How it happens |
67 |
-------------- |
68 |
All dev-lang/python ebuilds run a Bash function called |
69 |
"eselect_python_update" at the beginning pkg_postinst stage. |
70 |
Former function wraps a call to |
71 |
|
72 |
eselect python update ${eselect_python_options} |
73 |
|
74 |
|
75 |
Conclusion |
76 |
========== |
77 |
When you update GCC your system stays at a healthy state. |
78 |
You trigger the switch of active versions. |
79 |
|
80 |
With Python, when you install a newer version if gets activated, leaving |
81 |
your system in broken state. An update of Python always involves |
82 |
running python-updater. If the user/admin has to run that anyway, why |
83 |
should we take the call to eselect python off his shoulders, especially |
84 |
we break the system doing so? |
85 |
|
86 |
So I plan to remove the call to eselect_python_update from all Python |
87 |
ebuilds in two weeks from now. Besides Arfrever everybody I spoke to on |
88 |
this topic so far agreed to this approach. The two weeks window are to |
89 |
give people room to think and discuss about it. |
90 |
|
91 |
Please try to keep this thread as low-heat as possible. |
92 |
Thanks for reading. |
93 |
|
94 |
|
95 |
|
96 |
Sebastian |