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