1 |
If ever there was a frequently asked question, it's this, or the general |
2 |
family of "what's the best way to do an update in this situation?", like: |
3 |
|
4 |
>> What is a recommended way to update an old system to minimize |
5 |
>> the amount of broken ebuilds? |
6 |
|
7 |
> What's the best way to do an update of an old machine that |
8 |
> takes a long time to compile, or an embedded system? |
9 |
|
10 |
What's the best way to keep a machine completely up-to-date |
11 |
with the very latest, stability be damned?? |
12 |
|
13 |
What's the best way to keep a machine reasonably up-to-date, |
14 |
while keeping the machine stable and running? |
15 |
|
16 |
I couldn't find any of these in a FAQ on the gentoo website. Perhaps it's there |
17 |
and I missed it. But if indeed this FAQ lacks an answer, can we compose |
18 |
one from this discussion? |
19 |
|
20 |
Michael |
21 |
|
22 |
|
23 |
On Fri, 11 Nov 2005, Bob Sanders wrote: |
24 |
|
25 |
> On Fri, 11 Nov 2005 16:46:41 +0100 |
26 |
> Jimmy Rosen <listjiro@×××××.com> wrote: |
27 |
> |
28 |
> |
29 |
>> Primary: |
30 |
>> What is a recommended way to update an old system to minimize the |
31 |
>> amount of broken ebuilds? |
32 |
>> Is emerge --emptytree world a good idea? Is it better than a clean |
33 |
>> install? Or is the documentation's way good enough even for a very old |
34 |
>> system: |
35 |
>> emerge --update --deep --newuse world |
36 |
>> emerge --depclean |
37 |
>> revdep-rebuild |
38 |
> |
39 |
> For an old machine that takes a long time to compile, or an embedded system - |
40 |
> |
41 |
> emerge sync once per week and let it run over the weekend doing updates. |
42 |
> |
43 |
> About once per year - |
44 |
> - emerge sync |
45 |
> - ufed and check out the USE flags. Some changes occur and they need a |
46 |
> bit of cleaning. |
47 |
> - emerge -eav system (no need to d world.) |
48 |
> - emerge -uDNav world |
49 |
> - python-updater |
50 |
> - perl-cleaner all |
51 |
> - revdep-rebuild |
52 |
> |
53 |
>> I have an unexplainable fobia against --depclean though. |
54 |
> |
55 |
> Then don't. All you care about is the programs you currently use, those others |
56 |
> just sit there taking some space. If you're not obsessive about a little disk space, why |
57 |
> wipe them off the disk? |
58 |
> |
59 |
>> And updating |
60 |
>> everything at once seems a bit reckless, I mean with the age of the |
61 |
>> system it would update almost everything. The package list was a mile |
62 |
>> long, and you never know what will break. |
63 |
>> |
64 |
> |
65 |
> That's why you should keep on a regular update schedule. A lot of programs get |
66 |
> fixed, USE flags change, dependencies change, configuration options get updated. |
67 |
> |
68 |
>> Secondary: |
69 |
>> How often should one update the system to minimize hassles with broken |
70 |
>> packages? |
71 |
> |
72 |
> Me? I do most of my working systems daily - takes about 10 minutes for all 4 systems. |
73 |
> Home systems - daily or weekly. Laptop monthly. Better to see a small problem show |
74 |
> up than wait for it to be buried in a lot of updates and then have to find out which of |
75 |
> 10 or 20 packages caused the issue. |
76 |
> |
77 |
>> Too often, and the hassle of constant upgrading can get tedious even |
78 |
>> if it works ok, and too late, and some odd dysfunctional version |
79 |
>> combinations start showing up that the packages were not really |
80 |
>> tested for, leading to broken ebuilds. |
81 |
>> |
82 |
> |
83 |
> Have you run other distributions where you get the massive binary updates 3 times per year? |
84 |
> Have you had to fun of doing minor package updates in between the massive updates and |
85 |
> then find that the massive update leaves your system completely borked because of conflicts |
86 |
> with the minor updates? And I mean you don't see these until the system tries to reboot, and |
87 |
> then it sometimes won't do that. |
88 |
> |
89 |
>> |
90 |
>> |
91 |
>> I did like this: |
92 |
>> I didn't want to run a clean install or an --emptytree thingie. I |
93 |
>> wanted to take it a few steps at a time, so that if something broke I |
94 |
>> might have an idea about what new packages it was that broke it. |
95 |
>> |
96 |
>> 1) take a backup of the system. I have some modifications |
97 |
>> in /etc/init.d scripts and some extra non-gentoo stuff for clustering |
98 |
>> installed that I didn't want to risk, and I was pretty sure something |
99 |
>> would bork and leave me clueless. lol |
100 |
>> |
101 |
>> 2) emerge sync. Nice, worked. |
102 |
>> emerge *only the most important stuff* (oh, I'm really chicken btw): |
103 |
>> portage, baselayout, etc. |
104 |
>> That brought in some dependencies, but it worked out all right after a |
105 |
>> while and a lot of figuring out the /etc/init.d and config file |
106 |
>> changes that has happened for the last 1.5 years. And some other |
107 |
>> changes as to where certain configs go, and how, and so on. But most |
108 |
>> was easily searchable in docs or forums.gentoo or on this list. |
109 |
>> Reboot here to see if it even booted any more... YEEAAAH! |
110 |
>> |
111 |
>> 3) emerge basic user packages like gcc, glibc, xorg (yes I was still |
112 |
>> on xfree) kernel, etc. |
113 |
>> note: I have to stay on 2.4 because I use openmosix for the |
114 |
>> clustering, and I don't yet trust 2.6om. |
115 |
>> For this I started using --update --deep since I did want an updated |
116 |
>> system, but not all at once. |
117 |
>> This still worked out all right, with just some minor headaches of |
118 |
>> broken ebuilds. And some config files again. |
119 |
>> hrmmpf kernel change means reboot. darned. |
120 |
>> |
121 |
>> 4) emerge --update --deep desktop stuff like KDE, openoffice, |
122 |
>> browsers, etc... |
123 |
>> This started generating Looooooooots of broken packages. I have spent |
124 |
>> many hours looking through the _VERY_NICE_ bugs.gentoo.org. I still |
125 |
>> get bitten by bugs that are filed fixed in mid 2003. lol |
126 |
> |
127 |
> So here's something to chew on - you are running a cluster with a boat load |
128 |
> of desktop apps. And desktop apps have tons of libs that are needed. Plus |
129 |
> the desktop and their apps change a lot - there is a lot of churn in desktop apps. |
130 |
> They are going to break more often. Waiting will just make the breakage worse |
131 |
> and cause all the compiles to occur at one time, instead of being spread out. |
132 |
> |
133 |
>> Some more config file updates, and restarting all significant services |
134 |
>> to use the new software. |
135 |
>> |
136 |
>> 5) Now, muahaha, emerge --update --deep world. Aiaiai. Another batch |
137 |
>> of broken packages, but not the critical ones, since most everything |
138 |
>> necessary has already been updated. |
139 |
>> Some more config files. I _really_ like dispatch-config and cfg-update |
140 |
>> by now. |
141 |
>> |
142 |
>> 6) Well, I'm here now. The system works just fine. And yes, I recently |
143 |
>> remembered that I had forgotten to update the USE flags to cover the |
144 |
>> current situation (stooopid teflon memory). But I hope I can wait |
145 |
>> until the current few remaining problems are out of the way, and then |
146 |
>> I can perhaps (hope and pray) use the eminent and functional(?) |
147 |
>> --newuse (and I do so very much hope works with/as --deep). |
148 |
>> |
149 |
> |
150 |
> You should use them together - emerge -uDNav world |
151 |
> |
152 |
>> I still have some problems, mainly with skype, which works but have |
153 |
>> some odd dependency thingie with dbus that emerge doesn't like. And |
154 |
>> revdep-rebuild tries to bring in some stuff that are no longer in |
155 |
>> portage. Interesting, though, is that |
156 |
>> equery depends '=pack-group/packagename-x.y.z' |
157 |
>> doesn't report anything depending on those old packages any more after |
158 |
>> all the updates. How can I figure out what wants them? |
159 |
>> |
160 |
> |
161 |
> Try the packages with emerge -uDNav package package etc... |
162 |
> |
163 |
>> revdep-rebuild? is it safe to use, and safe with --package-names |
164 |
>> (since just about every single package it's trying to bring in is no |
165 |
>> longer in the portage tree) |
166 |
>> |
167 |
> |
168 |
> All it's doing is creating an - emerge, command. If you run - revdep-rebuild -p, |
169 |
> then at the end of the pretend mode, do a - rm -rf /root/.revdep-rebuild.*, |
170 |
> you can take the emerge line and do as many or as few as you want. |
171 |
> |
172 |
>> What somethingsomething-update programs should I run during the |
173 |
>> process? |
174 |
>> python-updater |
175 |
>> perl-clenaner |
176 |
>> java-config |
177 |
>> opengl-update |
178 |
>> modules-update |
179 |
>> --- what am I missing -- ? |
180 |
>> |
181 |
> |
182 |
> Nothing really if you do the --newuse, as well. |
183 |
> |
184 |
>> Is udev supported on 2.4.26+? would it be useful instead of devfs? and |
185 |
>> is there a *really* good guide for switching (that might warn me of |
186 |
>> the common problems I'm bound to run into)? |
187 |
>> |
188 |
>> |
189 |
> |
190 |
> No. Udev is 2.6 only. And a good guide is - |
191 |
> http://www.gentoo.org/doc/en/udev-guide.xml |
192 |
> |
193 |
>> |
194 |
>> In retrospect it might have been faster to simply do a reinstall or |
195 |
>> --emptytree. Sorry for issuing such a blasphemous statement on this |
196 |
>> list. |
197 |
>> |
198 |
> |
199 |
> No, you just need to do the system - emerge -e system |
200 |
> The rest will take care of itself through a emerge -uDNav world. |
201 |
> |
202 |
> Have fun! |
203 |
> |
204 |
> Bob |
205 |
> - |
206 |
> -- |
207 |
> gentoo-user@g.o mailing list |
208 |
> |
209 |
> |
210 |
-- |
211 |
gentoo-user@g.o mailing list |