1 |
Richard Freeman posted |
2 |
<33411.202.248.61.99.1129607716.squirrel@×××××××××××××××××.net>, excerpted |
3 |
below, on Mon, 17 Oct 2005 23:55:16 -0400: |
4 |
|
5 |
> On Mon, October 17, 2005 10:50 pm, Toby Fisher wrote: |
6 |
>> running system? Is it just a case of changing to an arch of ~amd64 and |
7 |
>> doing the upgrade? I'll bet it isn't which is why I'm asking here - |
8 |
>> I'd like not to have to start from scratch. |
9 |
>> |
10 |
>> |
11 |
> One tip I have is to avoid doing huge upgrades in a single shot, unless |
12 |
> it is on a testing-only chroot that you don't care about too much. |
13 |
> |
14 |
> I would probably do an emerge -puD world and look at the likely-huge |
15 |
> list of packages. I'd probably manually emerge stuff like portage / gcc |
16 |
> / glibc / toolchain early on. I'd also pick out stuff like base system |
17 |
> files, PAM-related stuff, and any stuff related to servers you depend on |
18 |
> (maybe samba servers for around the house, a webserver, etc). I'd |
19 |
> upgrade these individually so that you don't end up with a box that you |
20 |
> can't login to with no idea what broke it. Once you have the guts of |
21 |
> the system upgraded and the system can actually boot correctly then you |
22 |
> can upgrade the rest and just fix the occassional non-critical breakage |
23 |
> as you have time. |
24 |
|
25 |
Someone else mentioned this as well, and I'll third it. |
26 |
|
27 |
I /always/ do an emerge --pretend --update --deep world run first, so I |
28 |
have some idea of how big my upgrade is going to be. (I also use |
29 |
--verbose, so I get a look at the USE flags and can change anything I |
30 |
don't like. This is probably a VERY good idea upgrading to ~arch from |
31 |
stable, because it's almost certain some of the newer packages will have |
32 |
changed USE flags vs what you currently have merged.) After each level |
33 |
below, I run etc-update, so the number of pending updates doesn't get out |
34 |
of hand. Of course, if the current version of any package later in the |
35 |
process isn't enough for the new version of something early in the |
36 |
process, it'll bring in the dependency as necessary, so if that happens, |
37 |
naturally, do the dependency ordered thing rather than the order proposed |
38 |
below. |
39 |
|
40 |
After the emerge , if portage is to be upgraded, that's always the first |
41 |
thing I upgrade. The idea is that sometimes that upgrade might be fixing |
42 |
something subtly broken with an earlier version, or at least the newer |
43 |
version might be more efficient, so I always upgrade portage first. |
44 |
|
45 |
Then I upgrade things like gcc and binutils, because newer versions of |
46 |
those should make the compiled binaries of all the other packages that |
47 |
much improved. Also at this level would be autoconf/automake upgrades. |
48 |
|
49 |
Next are the general Unix utilities like util-linux, fileutils, file, |
50 |
grep, sed, gawk, etc, because as the utilities in these are often called |
51 |
from ebuilds, I want to be working with the latest versions when I emerge |
52 |
other stuff. |
53 |
|
54 |
Next would be linux-headers and glibc. |
55 |
|
56 |
Next are the system boot dependencies, baselayout with its boot scripts, |
57 |
udev, the kernel if you deal with it from portage (I manage mine |
58 |
separately, downloading, verifying authenticity, configuring/patching, and |
59 |
compiling, and installing, directly off of kernel.org, as I learned that |
60 |
with Mandrake before I ever switched to Gentoo, had my own set of scripts |
61 |
to deal with it, and saw no need to change what already worked well, when |
62 |
I switched to Gentoo), etc. |
63 |
|
64 |
At this point, after running etc-update, it's a good idea to reboot and |
65 |
ensure the new system layout still works. That's /always/ a /very/ good |
66 |
idea every time baselayout is upgraded. If something's strange with it, I |
67 |
want to find out about it right away. |
68 |
|
69 |
Note especially that baselayout is one of the packages that CAN screw up |
70 |
the system, and that ~arch means you are getting it after it works for the |
71 |
maintainer, but before it has been widely tested on all the different |
72 |
configurations out there, so sometimes something DOES go wrong with ~arch |
73 |
baselayout, and you end up either booting to emergency mode (thus directly |
74 |
to shell, without the regular sysinit based boot process, no system |
75 |
services running, nothing but root mounted, etc -- be sure you know how to |
76 |
do this if you run ~arch baselayout) or to your rescue partition or disk |
77 |
(I use a rescue partition that's in effect a known-working and |
78 |
tested-working snapshot of my working system, others prefer a LiveCD |
79 |
rescue disk of some sort). |
80 |
|
81 |
Further, you know the --changelog (-l) switch on emerge? Baselayout's a |
82 |
VERY good package to get in the habit of running that on (with --pretend, |
83 |
of course), to actually see what the changes are, before you merge it, so |
84 |
if there are issues, you have a good idea where they'll be and what sort |
85 |
of thing changed that might cause them, before you reboot and find it |
86 |
doesn't work, and haven't the foggiest! |
87 |
|
88 |
After the baselayout level and a successful reboot to test it, I run an |
89 |
emerge --update --deep --pretend --system, and see what else in system |
90 |
will be upgraded, if anything. Then I'll usually do that all together, |
91 |
completing the rest of the system level. |
92 |
|
93 |
After the system update is complete, I'll start on world, again doing the |
94 |
-puD thing first, to get a list. |
95 |
|
96 |
xorg is in world, and I'll almost always update it by itself. |
97 |
|
98 |
Next would be the likely fairly large group of packages that make up your |
99 |
preferred X environment. (Here, it's KDE.) Note that stuff like KDE is |
100 |
slotted, and you can configure to launch either version, old or new. I'll |
101 |
usually emerge the new base system (arts, kdelibs, the individual packages |
102 |
from kdebase that I have to to launch the new version) first, then test |
103 |
it, before emerging the rest. |
104 |
|
105 |
Everything else is more or less a matter of personal priority. Here, I'd |
106 |
continue by emerging the rest of a "functional" KDE system, so konqueror, |
107 |
kmail, and the like, before I did all the other "optional" packages, both |
108 |
KDE and others from the world step listed to upgrade. |
109 |
|
110 |
Some additional pointers... |
111 |
|
112 |
** Add FEATURES=buildpkg to your make.conf. That feature will cause |
113 |
portage to automatically create binary packages of everything it merges. |
114 |
This cann be quite useful for backup purposes, and comes in /very/ handy |
115 |
on an ~arch system when there's a problem with a newer version. If you |
116 |
have the older version still around as a binary package, you don't have to |
117 |
wait around for it to recompile, to revert to the older known working |
118 |
version. Of course, having several old versions pre-packaged is also handy |
119 |
when you haven't used an application in awhile, and want to find out where |
120 |
the problem was introduced so you can put the info in the bug report you |
121 |
file, narrowing down the possible issues to the changes between the last |
122 |
version that works and the first one that doesn't. |
123 |
|
124 |
FEATURES=buildpkg has saved my *** SEVERAL times. It's really something |
125 |
I'd now not want to do without, so I'd certainly recommend trying it. |
126 |
Depending on how many old package versions you keep around, expect on |
127 |
about a gig to two of packages. I have my packagedir on its own 1-G |
128 |
partition, which works, but is a bit cramped. I'll be putting it on a 2-5 |
129 |
gig partition next time I upgrade hard drives or rearrange partitions on |
130 |
what I have. |
131 |
|
132 |
** As I said but worth reemphasizing, if you are using ~arch (or even if |
133 |
using stable, but doubly so using ~arch), ensure you have a working rescue |
134 |
disk or partition. |
135 |
|
136 |
** The newest ~arch portage (or is it gentoolkit?) has a couple new tools. |
137 |
eclean is quite useful, for managing the size of your portage distdir and |
138 |
packagedir. It's very easy to run it and have it remove all the "dead" |
139 |
versions of source files and binpkgs, that don't have ebuilds in portage |
140 |
any longer, and that's very useful functionality to have! |
141 |
|
142 |
** Consider using the --oneshot switch with emerge. Here, I've created an |
143 |
alias that uses that by default. This keeps directly emerged packages |
144 |
from cluttering up your world file, which is handy when you are emerging |
145 |
by name system dependencies that really don't belong in the world file. |
146 |
Since --oneshot is now my default, I don't have to worry about it any more. |
147 |
|
148 |
** I believe it's already in stable portage, but as it's fairly new, many |
149 |
Gentoo users probably aren't aware of emerge's --newuse switch. This |
150 |
comes in handy for general system maintenance, allowing you to see what |
151 |
packages were merged with USE flags other than your current set. |
152 |
|
153 |
** After upgrading to ~arch, run revdep-rebuild (first with the -p option, |
154 |
of course), to clean up any old dependencies on outdated libraries that |
155 |
are no longer around. |
156 |
|
157 |
** Likewise, you'll probably want to run emerge depclean, to clean out any |
158 |
unneeded packages. IT'S **VERY** IMPORTANT TO RUN THIS WITH -p FIRST, |
159 |
CHECKING THE LIST FOR SANITY BEFORE YOU JUST LET IT REMOVE STUFF YOU KNOW |
160 |
YOU NEED. This is especially true if you take my suggestion and make |
161 |
--oneshot your default. You can then add any packages it wants to remove |
162 |
but that you know you need to keep to your world file, before letting it |
163 |
do its work on the remainder. Or... simply use the list it creates in |
164 |
pretend mode, to emerge -C individual packages manually, and never |
165 |
actually run emerge depclean without --pretend. |
166 |
|
167 |
After doing a depclean, it's generally wise to run revdep-rebuild once |
168 |
again, to catch any newly dependency-orphaned packages and remerge them to |
169 |
link them against newer libraries as necessary. |
170 |
|
171 |
Together, newuse, depclean, revdep-rebuild, and eclean, make maintaining a |
172 |
system as cruft free as possible under the more frequent update cycles of |
173 |
~arch, relatively painless. |
174 |
|
175 |
-- |
176 |
Duncan - List replies preferred. No HTML msgs. |
177 |
"Every nonfree program has a lord, a master -- |
178 |
and if you use the program, he is your master." Richard Stallman in |
179 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
180 |
|
181 |
|
182 |
-- |
183 |
gentoo-amd64@g.o mailing list |