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