1 |
Mark posted <1f81f7e005072806534ed43866@××××××××××.com>, excerpted below, |
2 |
on Thu, 28 Jul 2005 09:53:20 -0400: |
3 |
|
4 |
> Thanks to everyone who helped me get my system back after a couple of |
5 |
> world update snafus. Now of course I'm a little gun-shy about using |
6 |
> options like emerge --update world. So what's my best bet to keep my |
7 |
> system up to date, while protecting it from my own lack of understanding |
8 |
> of updating config files? |
9 |
> |
10 |
> Here's what I'm intending to do so far: |
11 |
> |
12 |
> 1. Prior to running any large system update, back up /etc to another |
13 |
> location 2. use dispatch-conf instead of etc-update |
14 |
> |
15 |
> Can anyone make any other suggestions? Which emerge options are best for |
16 |
> full system updates? Thanks |
17 |
|
18 |
One of the most useful things I've found here, is to add "buildpkg" to |
19 |
your make.conf FEATURES line. Portage will then emerge as normal thru the |
20 |
compile and fake-install stages, then instead of qmerging directly to your |
21 |
live file system, it will tarball up the resulting fake-install, attach |
22 |
the ebuild and some useful metadata to to make merging it easier, and file |
23 |
away the resulting binary package in your portage ${PKGDIR} |
24 |
(${PORTDIR}/packages, by default). It will then untar the binpkg it just |
25 |
created, and merge that, thereby ensuring the binpkg works as intended |
26 |
(thus avoiding the nasty surprise of a dud binpkg if you end up needing it |
27 |
later). |
28 |
|
29 |
This way, eventually, you'll have several back-versions of each package |
30 |
available in binary form, so if a new version of a package fails, you can |
31 |
simply emerge --packageonly your previous, known working, version, without |
32 |
having to go thru all the trouble recompiling what was just on your system |
33 |
before you merged the broken version! |
34 |
|
35 |
Among other things, this protects you from a gcc failure, as it'll be a |
36 |
simple matter to just remerge your last working gcc from the binary |
37 |
package, which won't require a working gcc to compile since it's a |
38 |
precompiled binary package! |
39 |
|
40 |
If portage itself (or python, which portage needs to function) breaks, |
41 |
again, no problem, because altho you can't use the broken portage to |
42 |
remerge itself, the binary package is actually just a tbz2 (tar.bz2) |
43 |
tarball including the files themselves, with that bit of portage metadata |
44 |
glued onto the end. Thus, (after backing up any config files you want to |
45 |
keep), simply extract the tarball over root, and it'll deploy a working |
46 |
portage once again. At that point, the portage database will have |
47 |
incorrect information about what version of portage (or python) itself is |
48 |
merged, but since portage is now working again, you'll be able to emerge |
49 |
--packageonly the package over itself, to get the portage database back in |
50 |
line with reality again, and clean up the loose ends. |
51 |
|
52 |
If tar or bzip2 break, you'll be unable to remerge them directly, using |
53 |
this technique, because portage needs them to extract the binary package. |
54 |
However, again, that's not an insurmountable problem. There are in fact |
55 |
two solutions. First, both those packages are comparatively easy to |
56 |
remerge the conventional way, from source, if necessary. Thus, you can |
57 |
do FEATURES=-buildpkg emerge bzip2 (or tar), to remerge without having |
58 |
portage try to use the broken binary packaging ability. Alternatively, |
59 |
you can copy working copies of the appropriate executable from your rescue |
60 |
partition or the LiveCD, over top of the borked copies, then use emerge -K |
61 |
to remerge your last previously working version. |
62 |
|
63 |
FEATURES=buildpkg comes in handy for other things as well, particularly |
64 |
for troubleshooting. Since I have a backup copy saved, if something quits |
65 |
working, it's easy for me to temporarily remerge and old version to check |
66 |
if it worked with it or if something else (possibly a library or other |
67 |
dependency) caused the breakage. |
68 |
|
69 |
*** VERY HANDY within the context of broken config files, since the |
70 |
binary packages save the default configs, if I want to see how my existing |
71 |
config compares to the default config, all I have to do is grab the |
72 |
default config out of the binary package and compare it with my existing |
73 |
version. |
74 |
|
75 |
Likewise, I can quickly compare scripts and default configs between |
76 |
versions, and compare files existing in the various versions with what's |
77 |
on my live system. |
78 |
|
79 |
Space required to store all those binary packages? 1-5 gigs, depending on |
80 |
how often you want to clean out all the old binary packages, how many |
81 |
packages you have installed, and whether you run amd64 or ~amd64 (the |
82 |
latter updating more frequently, resulting in more package versions to |
83 |
store). I have my $PKGDIR on its own dedicated partition, 1 gig, but |
84 |
running ~amd64, have to clean out old versions more frequently than I'd |
85 |
like. A 5 gig partition would have allowed me to do it only once a year |
86 |
or so. |
87 |
|
88 |
So, what if you like this idea, but haven't been doing it, and want to |
89 |
jumpstart your binary package collection with the packages you have |
90 |
currently merged? That's where quickpkg comes in. quickpkg allows you to |
91 |
make binary packages based on what's on your system at the moment, thus, |
92 |
avoiding having to recompile to get the binary package. Use "equery |
93 |
list" to get a list of what's currently merged. The list it returns isn't |
94 |
really formatted as we want, however, but with a bit of text processing |
95 |
wizardry... |
96 |
|
97 |
equery list|cut -d" " -f2|grep -v ^\*$ > package.list |
98 |
|
99 |
(The cut command cuts out the second field, -f2, with fields delineated by |
100 |
a space -d" ". The grep command is there to remove what otherwise ends up |
101 |
as the first line, after the cut, a single "*". The result is redirected |
102 |
to the file package.list.) |
103 |
|
104 |
That gives you a list of packages. You may want to open it in an editor |
105 |
and check it out, or split it into several smaller lists, to process one |
106 |
at a time. When you are satisfied, try this (substituting the filenames |
107 |
for the smaller lists if appropriate): |
108 |
|
109 |
for pkg in `cat package.list` ; do quickpkg $pkg; done |
110 |
|
111 |
(This simply creates a bash for loop, iterating over all the lines in the |
112 |
cat-ed file, executing quickpkg for each line.) |
113 |
|
114 |
quickpkg spits out info about what is doing, and will deal with slotted |
115 |
packages as needed, quickpkg-ing all merged versions, so that should do |
116 |
it. Keep in mind, however, that it's still a big job, even if it's not |
117 |
having to actually compile all those packages, so it'll take some time, |
118 |
which is why I suggested splitting up the list, above. Of course, you |
119 |
could simply do it while you were sleeping or away at work or something, |
120 |
if desired. |
121 |
|
122 |
-- |
123 |
Duncan - List replies preferred. No HTML msgs. |
124 |
"Every nonfree program has a lord, a master -- |
125 |
and if you use the program, he is your master." Richard Stallman in |
126 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
127 |
|
128 |
|
129 |
-- |
130 |
gentoo-amd64@g.o mailing list |