1 |
On 3/8/21 4:16 PM, Neil Bothwick wrote: |
2 |
> It would have to be done before the first update, when the repo was |
3 |
> set to a date just after the last update. |
4 |
|
5 |
Yes and no. |
6 |
|
7 |
It really could have been done at any point along the way. |
8 |
|
9 |
Also, with the git version of the portage repo, I could switch back to |
10 |
the branch from any time I wanted to. |
11 |
|
12 |
> You can rephrase that as "I left it at the default", which is an |
13 |
> acceptable answer :) |
14 |
|
15 |
*nod* |
16 |
|
17 |
> It means you probably spent a lot of time compile gcc versions only |
18 |
> to carry on using the old version, but as you said, this wasn't about |
19 |
> efficiency. |
20 |
|
21 |
Wouldn't the next execution of gcc, post Emerge & Installation use the |
22 |
newly emerged binary? |
23 |
|
24 |
If not next package in a given emerge run didn't use the new gcc, I |
25 |
would fully expect that subsequent emerges would use the new gcc. |
26 |
|
27 |
> You were going to emerge -e @world at the end anyway, which would |
28 |
> get everything built with the latest toolchain. |
29 |
|
30 |
Yes. |
31 |
|
32 |
I have initiated a full system backup. I'll start an `emerge -e @world` |
33 |
after that finishes. |
34 |
|
35 |
I'll actually do the full suite: |
36 |
|
37 |
1) emerge -e @world |
38 |
2) emerge --depclean --verbose n |
39 |
3) emerge @preserved-rebuild |
40 |
4) revdep-rebuild |
41 |
|
42 |
I expect that #3 should be a NoOp and just burn CPU cycles. |
43 |
|
44 |
I don't know anything else that can be done to make a Gentoo box happier |
45 |
(from a software standpoint). |
46 |
|
47 |
> Most of the effort for you was developing the procedure. All the real |
48 |
> effort was left to the computer. |
49 |
|
50 |
Exactly! |
51 |
|
52 |
Well, developing the method /and/ establishing trust therein. |
53 |
|
54 |
> I was thinking of a week max. |
55 |
|
56 |
I suspect that would be quite safe. |
57 |
|
58 |
|
59 |
|
60 |
-- |
61 |
Grant. . . . |
62 |
unix || die |