1 |
On Fri, 2021-04-30 at 01:50 +0100, Sam James wrote: |
2 |
> |
3 |
> > On 29 Apr 2021, at 22:01, Michał Górny <mgorny@g.o> wrote: |
4 |
> > |
5 |
> > Signed-off-by: Michał Górny <mgorny@g.o> |
6 |
> > --- |
7 |
> > .../2021-04-29-python3-9.en.txt | 93 +++++++++++++++++++ |
8 |
> > 1 file changed, 93 insertions(+) |
9 |
> > create mode 100644 2021-04-29-python3-9/2021-04-29-python3-9.en.txt |
10 |
> > |
11 |
> > diff --git a/2021-04-29-python3-9/2021-04-29-python3-9.en.txt b/2021-04-29-python3-9/2021-04-29-python3-9.en.txt |
12 |
> > new file mode 100644 |
13 |
> > index 0000000..3075d72 |
14 |
> > --- /dev/null |
15 |
> > +++ b/2021-04-29-python3-9/2021-04-29-python3-9.en.txt |
16 |
> > @@ -0,0 +1,93 @@ |
17 |
> > +Title: Python 3.9 to become the default on 2021-06-01 |
18 |
> > |
19 |
> |
20 |
> Thanks for working on this. I kept meaning to do one for 3.8 and then 3.9 got so close |
21 |
> that I felt a bit daft doing it. |
22 |
> |
23 |
> > + |
24 |
> > +We are planning to switch the default Python target of Gentoo systems |
25 |
> > +on 2021-06-01, from Python 3.8 to Python 3.9. If you have not changed |
26 |
> > +the values of PYTHON_TARGETS or PYTHON_SINGLE_TARGET, the change will |
27 |
> > +have immediate effect on your system and the package manager will try |
28 |
> > +to switch automatically on the next upgrade following the change. |
29 |
> |
30 |
> (Add a new line here). |
31 |
> |
32 |
> > +If you did change the values, prefer a safer approach or have problems |
33 |
> > +with the update, read on. |
34 |
> > + |
35 |
> > +Please note that the default upgrade method switches packages to the new |
36 |
> > +Python versions as they are rebuilt. This means that all interdependent |
37 |
> > +packages have to support the new version for the upgrade to proceed, |
38 |
> > +and that some programs may temporarily fail to find their dependencies |
39 |
> > +throughout the upgrade (although programs that are already started |
40 |
> > +are unlikely to be affected). |
41 |
> > + |
42 |
> > + |
43 |
> |
44 |
> I’d consider numbering or marking with a bullet point or ‘-‘ each of |
45 |
> the possible options, in order of likely usefulness. So, we’d do e.g. |
46 |
> |
47 |
> 1) If you’ve not set anything, just upgrade as normal and then depclean. |
48 |
> |
49 |
> 2) In order to have both Python implementations enabled temporarily for safety ,… |
50 |
> |
51 |
> […] |
52 |
> |
53 |
> But this isn’t required. It’s just about making it easier for people to see |
54 |
> what they need to do, and not misread it and then do silly things because |
55 |
> they just copied and pasted the stuff which looked right (it happens). |
56 |
> |
57 |
> Let’s put all of the key information at the beginning, then the |
58 |
> configurability/tweaking can be later on. |
59 |
> |
60 |
> > +If you wish to avoid changing Python targets at this moment, you can |
61 |
> > +force the old targets by setting your /etc/portage/package.use to e.g.: |
62 |
> > + |
63 |
> > + */* PYTHON_TARGETS: -* python3_8 |
64 |
> > + */* PYTHON_SINGLE_TARGET: -* python3_8 |
65 |
> > + |
66 |
> > +This will enforce Python 3.8 as the current target choice and block |
67 |
> > +any future updates. However, please note that this solution will only |
68 |
> > +be suitable for a few more months and you will eventually need to |
69 |
> > +perform the migration. |
70 |
> > + |
71 |
> > + |
72 |
> > +If you wish to use a safer approach to the migration and temporarily |
73 |
> > +preserve the support for Python 3.8 and Python 3.9 simultaneously, |
74 |
> > +set /etc/portage/package.use to: |
75 |
> > + |
76 |
> > + */* PYTHON_TARGETS: -* python3_8 python3_9 |
77 |
> > + */* PYTHON_SINGLE_TARGET: -* python3_8 |
78 |
> > + |
79 |
> > +Afterwards, rebuild your system with emerge's --changed-use option or |
80 |
> > +equivalent. This will cause your packages to gain Python 3.9 support |
81 |
> > +while preserving Python 3.8 support whenever possible. Then, change |
82 |
> > +the second line to: |
83 |
> > + |
84 |
> > + */* PYTHON_SINGLE_TARGET: -* python3_9 |
85 |
> > + |
86 |
> > +This will switch packages that can not support two Python versions |
87 |
> > +simultaneously, to use Python 3.9. Rebuild again. Finally, switch |
88 |
> > +the first line to the final version: |
89 |
> > + |
90 |
> > + */* PYTHON_TARGETS: -* python3_9 |
91 |
> > + |
92 |
> > +The next --changed-use rebuild will remove Python 3.8 support from your |
93 |
> > +packages. |
94 |
> > + |
95 |
> > + |
96 |
> > +You can also switch to Python 3.9 earlier by setting: |
97 |
> > + |
98 |
> > + */* PYTHON_TARGETS: -* python3_9 |
99 |
> > + */* PYTHON_SINGLE_TARGET: -* python3_9 |
100 |
> > + |
101 |
> > +If you choose to follow this or the previous approach, you may want to |
102 |
> > +remove the package.use overrides after the switch or just leave them |
103 |
> > +in place to protect your system from the next automatic upgrade |
104 |
> > +of Python. |
105 |
> > + |
106 |
> |
107 |
> “It is especially important you do not forget IF you choose to add this, |
108 |
> because it interferes with the natural rolling-with-the-defaults." |
109 |
> |
110 |
> > + |
111 |
> > +The Python 3.8 cleanup requires that Python 3.8 is removed from complete |
112 |
> > +dependency trees in batch. If some of the installed packages using |
113 |
> > +an older Python version are not triaged for the upgrade, the package |
114 |
> > +manager will throw dependency conflicts. This makes it important that |
115 |
> > +the upgrade is carried via a --deep --changed-use @world upgrade, |
116 |
> > +as well as that any stray packages are removed prior to it, e.g.: |
117 |
> > + |
118 |
> > + emerge --depclean |
119 |
> > + emerge -1vUD @world |
120 |
> > + emerge --depclean |
121 |
> > + |
122 |
> |
123 |
> Let’s put this right at the beginning. |
124 |
> |
125 |
> > + |
126 |
> > +By the time of the switch, it is quite probable that Python 3.10 will |
127 |
> > +already be available in ~arch Gentoo. Users wishing a more bleeding |
128 |
> > +edge experience may wish to switch to python3_10 target instead. |
129 |
> > +However, this is currently discouraged on stable as it will require |
130 |
> > +unmasking multiple ~arch packages as they gain Python 3.10 support. |
131 |
> |
132 |
> I was in two minds about keeping this, but it’s useful to give people an idea |
133 |
> of what’s coming in the future. |
134 |
> |
135 |
> > + |
136 |
> > +If you have PYTHON_TARGETS or PYTHON_SINGLE_TARGET declared |
137 |
> > +in make.conf, it is strongly recommended to remove the declarations |
138 |
> > +and use package.use as presented above. Use of make.conf to set flags |
139 |
> > +is discouraged as it does not respect package defaults. |
140 |
> |
141 |
> Let’s put this towards the beginning and also note that people should, in general, |
142 |
> not really need to set any PYTHON_TARGETS at all, other than for where packages |
143 |
> are lagging for having their support updated. |
144 |
> |
145 |
|
146 |
I've applied most of your suggestions... and feel like this still needs |
147 |
more work. I'll try to make it clearer what all options are, and how to |
148 |
use them. |
149 |
|
150 |
-- |
151 |
Best regards, |
152 |
Michał Górny |