1 |
Harm Geerts posted <200511021409.38666.harmgeerts@××××.nl>, excerpted |
2 |
below, on Wed, 02 Nov 2005 14:09:38 +0100: |
3 |
|
4 |
> On Wednesday 02 November 2005 05:30, Nick Currier wrote: |
5 |
>> Looks like that got it guys. Thanks tons for the help.... It seems I broke |
6 |
>> portage by running only part ~amd64 packages. revdep-rebuild found it but |
7 |
>> it took twice to fix..... depclean wants to get rid of tons of stuff though |
8 |
>> so I'm thinking this is a bad idea or I have bigger problems.... Kudos to |
9 |
>> AMD64 Gentoo for the best support team in open source. |
10 |
> |
11 |
> It's normal for a system that hasn't been maintained the way it should ;) |
12 |
|
13 |
Seconded. |
14 |
|
15 |
What depclean does is starting from your world file (and including stuff |
16 |
in your system profile that's not specifically listed in the world file), |
17 |
figure out what each package listed there needs to RUN (run-time |
18 |
dependencies, as opposed to compile-time dependencies), BASED ON CURRENT |
19 |
USE FLAGS, then unmerge other packages as unnecessary. |
20 |
|
21 |
This is why it's important to try it with --pretend, first, and check the |
22 |
list for sanity. There are a number of reasons something might be listed |
23 |
for removal that needs to be kept. |
24 |
|
25 |
1. Occasionally, there might be something NOT listed in your world file |
26 |
(and that isn't a dependency of anything else) that you want. These are |
27 |
easy enough to append to your world file, removing them and their |
28 |
dependencies from the list. |
29 |
|
30 |
2. USE flags affect dependencies, in many cases. If you merged something |
31 |
with one set of use flags, resulting in it linking against a particular |
32 |
library, then you changed your USE flags, so it would NOT link against it |
33 |
now, but you still have the old version, linked against that library, |
34 |
merged, then depclean will want to remove the library (because the current |
35 |
USE flags say it isn't needed), but doing so will break the currently |
36 |
merged package with outdated USE flags linked against it. |
37 |
|
38 |
This is why it's a good idea to run emerge --newuse (-N) --deep (-D) |
39 |
--update (-u) first. Doing so should find those currently merged packages |
40 |
with outdated USE flags and remerge them with current USE flags, thus NOT |
41 |
linking against that no longer needed library, allowing it to be unmerged |
42 |
without killing the stuff that formerly depended on it. |
43 |
|
44 |
It's also why running revdep-rebuild afterward, not just before, is a good |
45 |
idea. Doing so afterward catches anything that slipped thru the cracks |
46 |
the first time. |
47 |
|
48 |
3. Note the emphasized RUNTIME above. The easiest way to explain this |
49 |
one is with a real example, taken from my experience. |
50 |
|
51 |
Example: k3b is probably the Linux world's best and most recognized all |
52 |
around CD/DVD burner, ripper, and media transcoder, all in one. With |
53 |
various USE flags set, it'll bring in as dependencies transcode and a |
54 |
bunch of different media codec libraries, that allow transcode to do its |
55 |
thing, converting from one media format to another on-the-fly. k3b of |
56 |
course then uses transcode as one of its tools, to help it convert between |
57 |
various formats, as well. |
58 |
|
59 |
The thing is, as the k3b ebuild is currently setup, transcode and a bunch |
60 |
of these media codec libraries are configured as MERGE TIME dependencies, |
61 |
NOT RUNTIME dependencies. Thus, depclean will want to remove them, which |
62 |
probably isn't what you want, if you had k3b USE flags setup to pull them |
63 |
in in the first place. Appending all the affected packages to the world |
64 |
file will prevent depclean from removing them as unneeded at runtime. |
65 |
|
66 |
That's probably one of the more extreme examples of where depclean will be |
67 |
almost GUARANTEED to do the wrong thing, if you don't check what it's |
68 |
going to do, and do that append before letting it do its thing. However, |
69 |
the same principle likely applies in other cases as well. Even where |
70 |
packages may not be actually used except to compile packages you /do/ use, |
71 |
you may want them in your world file, just to prevent depclean from |
72 |
unmerging them, and therefore having to remerge them the next time the |
73 |
package you want, that has them as merge-time only dependencies, gets |
74 |
upgraded. |
75 |
|
76 |
ALTERNATIVE/HINT: This is yet another place where FEATURES=buildpkg comes |
77 |
in handy. If you have portage automatically creating binary packages of |
78 |
everything you merge, you don't have to be quite as careful with depclean. |
79 |
If it removes something you decide you want, simply remerge the binpkg, |
80 |
avoiding the hassle of having to recompile the package from scratch. If |
81 |
you are NOT running FEATURES=buildpkg, yet you aren't sure if something's |
82 |
needed or not, try using quickpkg to package up the existing package as |
83 |
currently deployed on your system, before unmerging it. As above, if you |
84 |
find you needed the package after all, simply emerge -k it, and the |
85 |
binpkg you quickpackaged should be remerged, avoiding that extra recompile |
86 |
time. |
87 |
|
88 |
> 1. Look over the list of packages that would be unmerged with: |
89 |
> # emerge --pretend depclean |
90 |
> 2. Inject the packages that should not be removed in your world file with: |
91 |
> # emerge --noreplace <package name> |
92 |
|
93 |
Hmm... That --noreplace is a new one on me. I normally simply |
94 |
|
95 |
echo <category/pkg> >> /var/lib/portage/world |
96 |
|
97 |
That appends the echoed cat/package to the end of the named file, |
98 |
accomplishing what we are after. The only down side to doing it manually |
99 |
(using echo) is if you typo. Still, that's not hard to catch and fix, if |
100 |
depclean still wants to remove the package you (thought you) just added. |
101 |
Newer versions of portage (don't believe it's in stable portage yet) even |
102 |
have an emaint command that removes the bad lines for you. |
103 |
|
104 |
> Repeats steps 1 and 2 untill you are satisfied. |
105 |
|
106 |
> 3. clean the remaining packages with: |
107 |
> # emerge --ask depclean |
108 |
|
109 |
Note that there's nothing magical about the depclean command itself, other |
110 |
than the fact that it automatically computes the dependencies and finds |
111 |
what can be unmerged, for you. Once it comes to the unmerge itself, |
112 |
that's really all it does. |
113 |
|
114 |
Consequently, here, I'll usually do an emerge --pretend depclean, then |
115 |
simply use the list to add packages to the world file or manually emerge |
116 |
--unmerge them. I very rarely run emerge depclean without the --pretend; |
117 |
that is, I don't often let it do the unmerging on its own. Rather, I use |
118 |
it to get a list, and do the unmerging directly, myself. No big deal, |
119 |
it's just a matter of style, but I feel more in control doing it myself. |
120 |
=8^) |
121 |
|
122 |
One thing about doing the unmerges manually, however, is that if the list |
123 |
is a bit long, one can unmerge stuff as they decide they don't need it, or |
124 |
add it to the world file as they decide they do, thus dealing with the |
125 |
list a bit at a time. Whittling the list down this way, one can |
126 |
repeatedly run depclean pretend, addressing just a few packages each time, |
127 |
until the list gets to a rather more manageable size -- something that |
128 |
might help if depclean hasn't been run in awhile. |
129 |
|
130 |
> 4. rebuild packages that were built against older/removed libaries: |
131 |
> # revdep-rebuild --pretend (part of app-portage/gentoolkit) |
132 |
> |
133 |
> In order to keep your system clean in the future upgrade world like |
134 |
> this: |
135 |
> 1. upgrade your world, remerge packages that have a changed USE |
136 |
> flag and upgrade deep dependencies. |
137 |
> # emerge --ask --deep --newuse --upgrade world |
138 |
> 2. rebuild packages that were built against older/removed libaries |
139 |
> # revdep-rebuild --pretend |
140 |
> |
141 |
> If you ever remove a package do it like this: |
142 |
> 1. remove the package |
143 |
> # emerge --ask --unmerge package |
144 |
> 2. remove the dependencies but always check the output. other packages |
145 |
> might use them even though they are not a direct dependency |
146 |
> # emerge --ask depclean |
147 |
> 3. rebuild packages that were build against libaries you just removed |
148 |
> # revdep-rebuild --pretend |
149 |
> |
150 |
> This is how I maintain all my systems. If anyone has remarks/tips I'd be |
151 |
> glad to hear them. |
152 |
|
153 |
Very well written! My tips, mainly the FEATURES=buildpkg or quickpkg |
154 |
thing, to get binary packages and avoid a possible recompile during a |
155 |
possible remerge, if you are unsure, and the individual package removal |
156 |
thing, are above, but they are mainly a matter of personal style. Your |
157 |
system hygiene routine is top notch! |
158 |
|
159 |
Two more things... |
160 |
|
161 |
1. I already mentioned one of the new features of the new portage |
162 |
(2.0.53, now in the rc stage in ~arch), emaint, that helps clean invalid |
163 |
entries out of the world file. The new portage has another useful new |
164 |
tool as well, eclean. eclean is designed to help manage the accumulated |
165 |
source tarballs in $DISTDIR, cleaning out the ones that no longer match |
166 |
anything in portage, by default, or if desired, cleaning out all the |
167 |
tarballs that don't match packages currently merged (older tarballs |
168 |
for packages with ebuilds still in portage, mainly). For those using |
169 |
FEATURES=buildpkg, eclean can manage the $PACKAGEDIR the same way, |
170 |
deleting binary packages no longer matching anything in portage by |
171 |
default, or getting stricter and deleting packages not matching stuff |
172 |
currently merged, if desired. |
173 |
|
174 |
eclean started out as one of several tools authored and contributed |
175 |
by Gentoo users, that did much the same thing. It was selected for |
176 |
inclusion in portage because it matched the way portage worked already, |
177 |
and because it did its job well. For those still running portage 2.0.52 |
178 |
(stable), eclean is available as a separate package, altho it's not in the |
179 |
tree. I believe it can be found in the forums. |
180 |
|
181 |
2. All this should reemphasize the role of the world file. It should |
182 |
list all your "leaf" packages, for the most part, executables. It should |
183 |
NOT list "trunk and branch" packages, dependencies of the leaves, for the |
184 |
most part, libraries and the like. |
185 |
|
186 |
The problem with branch dependencies listed in the world file is that when |
187 |
the leaf dependencies that use them are no longer needed and are unmerged, |
188 |
depclean still won't try to remove them, because they are listed in the |
189 |
world file, even tho they are no longer needed. OTOH, not listing leaf |
190 |
dependencies in the world file means depclean will try to remove them, |
191 |
when they are something you WANT to keep. |
192 |
|
193 |
Depclean, therefore, is the only tool around that helps to remove stale |
194 |
dependencies after the packages using them have been unmerged. Without |
195 |
it, the leaf packages may be removed from the world file and unmerged, but |
196 |
the dependencies they brought in continue to hang around, becoming a |
197 |
breeding ground for possible bugs and security vulnerabilities, in |
198 |
addition to the space they take up and the the directories they fill. |
199 |
|
200 |
HINT: For this reason, here, I've created a set of aliases I use instead |
201 |
of calling emerge directly. By default, now, I call emerge --oneshot, |
202 |
which will NOT add stuff I emerge to the world file. That way, I can |
203 |
emerge dependencies to my heart's content, without worrying about having |
204 |
them clogging up my world file. In the event I'm actually emerging a new |
205 |
"leaf" package that's not in the world file yet, I either don't use those |
206 |
aliases, so it's added to the world file, or (more likely since it's |
207 |
habit) use the aliases, but then add them to my world file manually, the |
208 |
next time I run depclean and find them listed. |
209 |
|
210 |
-- |
211 |
Duncan - List replies preferred. No HTML msgs. |
212 |
"Every nonfree program has a lord, a master -- |
213 |
and if you use the program, he is your master." Richard Stallman in |
214 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
215 |
|
216 |
|
217 |
-- |
218 |
gentoo-amd64@g.o mailing list |