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