1 |
On 3/8/21 3:29 PM, Neil Bothwick wrote: |
2 |
> With hindsight, removing firefox, thunderbird and libreoffice and |
3 |
> replacing them with their -bin counterparts at the start of the |
4 |
> process would have saved much time. You could switch back to the |
5 |
> source options once the system is up to date. |
6 |
|
7 |
You're probably correct. |
8 |
|
9 |
However I don't think I would do that even if I had known / thought |
10 |
about doing so. Partially because changing things was questionable at / |
11 |
near the start and partially because this was about possibility, not |
12 |
efficiency. |
13 |
|
14 |
> How did you manage gcc upgrades, did you run gcc-config manually |
15 |
> whenever gcc was updated? |
16 |
|
17 |
Is "I ignored them and let emerge deal with it" count? I did see gcc |
18 |
upgrades along the way. |
19 |
|
20 |
I don't remember what it was at the start, probably 8.<something> or |
21 |
9.<something>. I did see 9.3 somewhere along the way. gcc -v says that |
22 |
10.2.0 is currently installed. |
23 |
|
24 |
> Do you feel it was worth the effort of updating for every day of the |
25 |
> git history? |
26 |
|
27 |
I don't know if it was worth the effort or not. I initially did one day |
28 |
at a time while testing the waters and going from theory to some |
29 |
practical experience of the method. |
30 |
|
31 |
Very quickly I used a different version of e (1 or 2) that took the date |
32 |
as a parameter. My command line was calling e with the date derived |
33 |
from the d variable and then decrementing the d variable after the e |
34 |
function finished. I.e. |
35 |
|
36 |
e $(date +%Y-%m-%d -d "$d days ago"); $((d=$d-1)) |
37 |
|
38 |
I would let that run, deal with any results, then hit the up arrow and |
39 |
enter. |
40 |
|
41 |
I just let that process continue for a while. Then at some point I |
42 |
optimized it into e3 and ran that for a while. Then I optimized that |
43 |
into the while e3; do true; done loop. |
44 |
|
45 |
But I stuck with single day steps mostly from inertia. It was working. |
46 |
So ... stick with it. |
47 |
|
48 |
> Would a larger increment have saved time, or did you think minimising |
49 |
> the number of issues to deal with after each emerge was more important? |
50 |
|
51 |
Maybe. If anything, it would have saved the time for emerge to process |
52 |
all of it's meta data. Much like an initial emerge vs an emerge |
53 |
--resume. But again, this was about the viability of the process, not |
54 |
the efficiency thereof. |
55 |
|
56 |
I probably could have gone with a week at a time. I don't know if that |
57 |
would have helped or not. I don't think I would go with more than a |
58 |
week with a largely automated process. |
59 |
|
60 |
I think one month increments probably would be pushing the envelope. I |
61 |
feel like some of the Python changes were 2 or maybe 3 months apart. So |
62 |
with two combined with how you landed, you might cross Python 3.6 w/o |
63 |
3.7, to both 3.6 and 3.7, to w/o 3.6 and w/ 3.7 barrier. That probably |
64 |
wouldn't be pretty. |
65 |
|
66 |
> Anyway, glad it worked for you - it's more or less how I would have |
67 |
> approached it but never had to, so thanks for doing the legwork :) |
68 |
|
69 |
You're welcome. |
70 |
|
71 |
Hence the DenverCoder9 comment, for people searching ~> reading the |
72 |
mailing list archive in the future. |
73 |
|
74 |
|
75 |
|
76 |
-- |
77 |
Grant. . . . |
78 |
unix || die |