Gentoo Archives: gentoo-user

From: Jimmy Rosen <listjiro@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] What is recommended behavior for complete updating of an old system ?
Date: Tue, 15 Nov 2005 05:57:13
Message-Id: 200511150650.09726.listjiro@gmail.com
In Reply to: Re: [gentoo-user] What is recommended behavior for complete updating of an old system ? by michael@michaelshiloh.com
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