1 |
On Tue, Jul 5, 2022 at 12:36 PM Jack <ostroffjh@×××××××××××××××××.net> wrote: |
2 |
> |
3 |
> On 2022.07.05 12:24, Grant Edwards wrote: |
4 |
> > On 2022-07-05, William Kenworthy <billk@×××××××××.au> wrote: |
5 |
> > |
6 |
> > > I synced portage a couple of days now and now my systems are |
7 |
> > rebuilding |
8 |
> > > python modules for 3.10 without any input from me [...] |
9 |
> > |
10 |
> > Every time there's a Python upgrade like this, it turns into a bit of |
11 |
> > an ordeal because I always have a small handful of packages that don't |
12 |
> > support the newer version. |
13 |
> > |
14 |
> > The news item offers no advice on what to do in this situation other |
15 |
> > than completely postponing the upgrade of everything (which doesn't |
16 |
> > seem like the best choice.) |
17 |
> > |
18 |
> > It would be nice if the news item explained how to let the upgrade |
19 |
> > procede while holding back a few packages. |
20 |
> > |
21 |
> > Can you set 3_9 and 3_10 globally, and then disable 3_10 for a few |
22 |
> > individual packages that can't be built with 3_10? |
23 |
> As far as I can tell, you just need to add python_targets_python3_9 for |
24 |
> the package in the appropriate package.use file. |
25 |
> |
26 |
|
27 |
That and its dependencies. Obviously you need to be caught up before |
28 |
things get removed from the repo, but the offending package itself |
29 |
will get removed when that happens anyway. |
30 |
|
31 |
You can always just globally keep the older version around longer if |
32 |
you don't want to deal with a bunch of cruft in |
33 |
/etc/portage/package.use. The news item explains how to do this. |
34 |
|
35 |
-- |
36 |
Rich |