Gentoo Archives: gentoo-user

From: michael@×××××××××××××.com
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] What is recommended behavior for complete updating of an old system ?
Date: Mon, 14 Nov 2005 06:52:23
Message-Id: Pine.LNX.4.64.0511132028000.21898@mail.magrittesystems.com
In Reply to: Re: [gentoo-user] What is recommended behavior for complete updating of an old system ? by Bob Sanders
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

Replies