1 |
"Daiajo Tibdixious" <daiajo@×××××.com> posted |
2 |
a4a9bfcb0701291821l47ea160pa76a94f1f52da661@××××××××××.com, excerpted |
3 |
below, on Tue, 30 Jan 2007 13:21:57 +1100: |
4 |
|
5 |
> [This sort of continues from "unmerging slotted group packages" which |
6 |
> drifted into general gentoo maintenance, and hence my first --depclean |
7 |
> since inception.] |
8 |
> revdep-rebuild is pulling up hundreds of broken links since the depclean. |
9 |
> A large group of them are in /usr/lib32. |
10 |
> A while ago I got rid of all emulation programs (firefox-bin, |
11 |
> mplayer-bin) and all of the emul-linux-* packages. |
12 |
> I've been putting back via --usepkg everything revdep-rebuild comes up |
13 |
> with but it doesn't help at all, so I've switched to looking at the |
14 |
> raw "broken /usr/lib32/blah_calls (requires blah_so)"; |
15 |
> doing an 'equery belongs blah_calls' which usually brings up nothing, |
16 |
> or a 64 bit application, then I manually delete the |
17 |
> /usr/lib32/blah_calls.so file. |
18 |
> This will get the job done (I believe), however is incredibly tedious. |
19 |
> |
20 |
> So, can I simply rm /usr/lib32/* ? |
21 |
|
22 |
You probably want to run equery b /usr/lib32, and see what's still using |
23 |
it. I have no 32-bit only packages here, but on a multilib profile |
24 |
system (including mine), you will almost certainly find at least a couple |
25 |
packages using it, including glibc and sandbox (from portage). This is |
26 |
because they include both 64-bit and 32-bit components, to support 32-bit |
27 |
stuff if you want to run it. |
28 |
|
29 |
Having found the packages that use the dir, you can run equery f <pkg>, to |
30 |
get a listing of files for the package, and see what each one uses in that |
31 |
dir. Anything /not/ listed as being used by those packages /may/ be safe |
32 |
to remove. However, my usual routine is rather more cautious. I move |
33 |
stuff I'm not sure about to something like (in this case) |
34 |
/usr/lib32.remove, and carry on using the system for awhile. If a month |
35 |
or so later nothing has complained, then I go ahead and remove it. |
36 |
|
37 |
Another alternative to running equery f and seeing what belongs to |
38 |
each package, is to do something like this: |
39 |
|
40 |
for file in /usr/lib32/*; do equery b $file; done |
41 |
|
42 |
That takes a somewhat longer to process but is a bit more automated. Any |
43 |
searching for... entry that doesn't have a corresponding package is a file |
44 |
portage doesn't directly anyway know anything about. |
45 |
|
46 |
Note that either way, some of those files might still be used by eselect |
47 |
(generally symlinks in its case), or be otherwise useful files that weren't |
48 |
installed by portage, but with a bit of sysadmin sense, you can figure out |
49 |
if they are orphaned or useful, and delete the orphaned ones, keeping |
50 |
anything useful, and *.remove-ing everything you're not sure about to see |
51 |
if it's actually still used or not. In the context of revdep-rebuild, |
52 |
however, particularly for 32-bit stuff which except for the multilib |
53 |
toolchain isn't going to be critical for operation of a 64-bit system, |
54 |
it's generally safe to say that any real *.so* files portage doesn't know |
55 |
about are likely to be orphaned and therefore safe to remove, while any |
56 |
symlinks to such files need further investigation. Native executable |
57 |
binaries likewise. Watch out for config files and anything scripted, |
58 |
altho normally those shouldn't be in lib32 anyway, but there may be |
59 |
certain abnormal exceptions. |
60 |
|
61 |
At one point I had a hard drive go bad, or rather, parts of it go bad, |
62 |
due to overheating. At the time, I had /var and /usr on separate |
63 |
partitions, with older backup versions of each. When part of the drive |
64 |
went bad, however, it took only some of the partitions, and I ended up |
65 |
running a system with a new /var (and thus portage database) and /, but |
66 |
an old /usr. Thus the files on /usr didn't agree with what was in the |
67 |
portage database. While I was able to remerge all the packages the |
68 |
portage database in /var said were merged, thus getting all the right |
69 |
files on /usr, that didn't take off all the old ones, and I had a LOT of |
70 |
orphaned files. I used for loops like the one above to help me track |
71 |
down what was supposed to be there and what wasn't, so I could remove it. |
72 |
Thus, it's fair to say I have rather more experience dealing with this |
73 |
than I'd like. =8^( |
74 |
|
75 |
After that, I updated to a four-drive kernel md-RAID arrangement, with |
76 |
all my critical stuff on RAID-6, so I can lose two drives at once without |
77 |
loss of critical or system data. I also have a bit better cooling for |
78 |
the drives, altho I'm not sure that would have helped in the situation |
79 |
that took down the old one, an AC failure here in Phoenix, in the middle |
80 |
of the summer, where the room itself was likely 50 C possibly hotter, so |
81 |
who knows /how/ hot the drives got in the computer. Anyway, when I redid |
82 |
the filesystems on the RAID layout, I kept everything that portage |
83 |
normally installs stuff to on the same partition as its database (so /, |
84 |
/var, and /usr are all on the same partition, and I split off /usr/local, |
85 |
/var/log and the like instead), so when I image that partition for backup, |
86 |
everything portage knows about stays in sync and I shouldn't have to worry |
87 |
about at least /that/ sort of orphaning again. Lesson learned from |
88 |
experience, I guess. |
89 |
|
90 |
-- |
91 |
Duncan - List replies preferred. No HTML msgs. |
92 |
"Every nonfree program has a lord, a master -- |
93 |
and if you use the program, he is your master." Richard Stallman |
94 |
|
95 |
-- |
96 |
gentoo-amd64@g.o mailing list |