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