1 |
n952162 wrote: |
2 |
> On 12/13/20 9:06 PM, Dale wrote: |
3 |
>> |
4 |
>> I agree. I update once a week. It seems a pretty good balance between |
5 |
>> not having to do it to often and not having such drastic changes that it |
6 |
>> makes things hard to work through. |
7 |
>> |
8 |
>> That said, when the tree is in the process of huge changes, it can |
9 |
>> create problems even with weekly updates. Right now, it is python and |
10 |
>> the speed it is moving at. Some versions that have been around for |
11 |
>> ages, 2.7, is being removed. Then python 3.6 is leaving etc etc etc. |
12 |
>> Those of us that have been around long enough have seen this with other |
13 |
>> packages as well. Some packages are just hard to upgrade to begin with |
14 |
>> and some create circular problems. The longer it goes between updates, |
15 |
>> the larger that problem gets to be. You get two different packages |
16 |
>> doing that, you can find yourself running around in circles trying to |
17 |
>> get emerge to chew what it can. |
18 |
>> |
19 |
>> While I usually do updates on Sunday evening, I'm considering doing |
20 |
>> twice a week, Sunday and Wednesday. At least until python settles down |
21 |
>> a bit. Thing is, I think the worst part may be about over. I think 2.7 |
22 |
>> is gone here, I think 3.6 is too. That's two down. It seems 3.7 and |
23 |
>> above will be around a while but if they start going away soon, I may do |
24 |
>> two updates a week if it starts making updates harder. |
25 |
>> |
26 |
>> Time can be a problem but sometimes it just depends on what packages |
27 |
>> have changed and how fast they have changed. For some systems that |
28 |
>> haven't been updated in a while, having to remove python 2.7 and 3.6 in |
29 |
>> one go, can cause problems that are hard to get around. Right now just |
30 |
>> isn't a good time to let updates get to far apart. |
31 |
>> |
32 |
>> The only thing that makes some of this survivable, getting help on this |
33 |
>> mailing list. Some people can decode the output of emerge and find a |
34 |
>> way to work through it. Some are fairly easy, some not so much. |
35 |
>> Sometimes removing/commenting out things in the world file will help. |
36 |
>> Sometimes doing @system first helps. Sometimes you just have to update |
37 |
>> certain packages in small chunks to get through a upgrade. Finding that |
38 |
>> right option sometimes requires help. |
39 |
>> |
40 |
>> Just some thoughts. |
41 |
>> |
42 |
>> Dale |
43 |
>> |
44 |
>> :-) :-) |
45 |
>> |
46 |
>> |
47 |
>> |
48 |
> |
49 |
> My problem is I can't find a diagnostic methodology. The one I most |
50 |
> often hear is, update more often, or trail and error solutions. |
51 |
> |
52 |
> Does all that information in emerge's output point the way to the |
53 |
> problem, and I just have to learn to understand it, or am I just |
54 |
> wasting my time there? Are there better tools than log parsing? I know, |
55 |
> there are lots of good tools, but there needs to be methodology for |
56 |
> using them (like understanding gentoo ;-) ) |
57 |
> |
58 |
> |
59 |
> |
60 |
|
61 |
|
62 |
I been using Gentoo for a good long while and most of the time, I still |
63 |
can't understand what it spits out onto my screen. I've seen some say |
64 |
to start at the bottom, then work your way up. Even with that, it |
65 |
doesn't help me understand it most times. Generally, I do some trial |
66 |
and error. If that fails, post to this list including everything I can |
67 |
that is relevant. |
68 |
|
69 |
I think the thing that has helped me the most, good defaults when |
70 |
updating the system. I set the -1 emerge option as a default to keep |
71 |
the world file clean. After that, the rest is about updating as deep as |
72 |
I can to keep things as sane as possible. Sure, it may update things |
73 |
other options would leave out but it gives me a more stable system. |
74 |
It's rare that I have software crash. It happens but is usually cleared |
75 |
up with the next upgrade. I don't have them because of some mismatch |
76 |
between different versions of software tho. Doing just a plain emerge |
77 |
-u world is not near as good as emerge -uUDN world. Just the -D will |
78 |
make a big difference. |
79 |
|
80 |
I posted this before but not sure what thread it was. This is my |
81 |
default options from make.conf. Keep in mind, this links to the real |
82 |
one in /etc/portage. I'm still used to the old location. |
83 |
|
84 |
|
85 |
root@fireball / # cat /etc/make.conf | grep emerge |
86 |
EMERGE_DEFAULT_OPTS="--with-bdeps y --backtrack=100 --keep-going -v -j5 |
87 |
--quiet-build=n -1 --unordered-display" |
88 |
root@fireball / # |
89 |
|
90 |
|
91 |
I haven't adjusted that in a while but may look into it later. I've |
92 |
seen a few posts about some new options. Over the years tho, that has |
93 |
given me a pretty stable system. Depending on what packages are getting |
94 |
updated upstream, one may can wait a month or so between updates. At |
95 |
times tho, weekly may be a lot easier. It reminds me of the old |
96 |
question; how do you eat a elephant? One bite at a time is a lot easier |
97 |
than trying to swallow it whole. Updating a Gentoo system is sort of |
98 |
the same way. It is a lot easier than it was 10 or 15 years ago tho. |
99 |
|
100 |
Just some ideas and how I do things. Your mileage may vary. |
101 |
|
102 |
Dale |
103 |
|
104 |
:-) :-) |