Better way to clean up?

whoops · 2010-07-15 14:47:40

Hi!

I'm afraid I had a few things screw around in places where they shouldn't in the past (p.e. "3rd party package managers" that don't seem to uninstall that neatly like that one perl module download thing, a wine helper program or something and stuff like this). Also there's the ever growing cache & log directories. At the moment, I'm just doing...

LC_ALL=C find /bin /opt /sbin /usr /var /etc -type f -exec pacman -Qo {} \; | grep "No package owns"

... and looking through the matches for files that can safely be delete. But that (1) takes an awful long time to create & look trough the list and (2) isn't all that great, especially when it comes to orphan config files that are spread around in /etc and maybe the user home. Also, all those cache directories that are located in various places are starting to grow sort of big, but while I'd like to strip down on "log spam" a bit, I don't really want to delete all of this... the thought of doing it pseydo-manually gives me the creeps though (some things like the package cache could most likely just be done by last change date, others might require some parsing around to find & delete p.E. changes I undid later or even redid multiple times and that just aren't relevant any more...) and just isn't worth it.

Any less awkward starting points to this task (no, not just yet a clean new arch installation... it's still more of a "cosmetic" thing, this machine should manage just fine without a reinstall for another 3-5 years if I don't do something unexpectedly stupid)?

Thanks!

Last edited by whoops (2010-07-15 14:48:12)

karol · 2010-07-15 15:23:17

Arch is very easy to set up so I'd go w/ a clean install but I don't mind having 100 "extra" (i.e. unnecessary) packages - I test things out, help folks on the forum - which sometimes involves installing the app they have problems with. I keep notes - pacman outputs like this:

Targets (3): libunique-1.1.6-2 [0,05 MB]  libnotify-0.4.5-1.1 [0,03 MB]
             midori-0.2.6-1 [0,52 MB]

I've installed midori to check sth out and I'm going to remove it tomorrow. The other two packages should be removed too, but just in case they're not, I'm going to check if they're still here after the weekly clean-up.

anonymous_user · 2010-07-15 15:27:57

I don't think whoops wants to clean up unnecessary packages, but rather the files left behind after uninstalling the packages.

karol · 2010-07-15 15:33:43

> I don't think whoops wants to clean up unnecessary packages, but rather the files left behind after uninstalling the packages.
Yeah, I get it, but unless those files can do harm I'd leave them there OR reinstall the whole thing.

whoops · 2010-07-15 15:48:05

Oh...

When it comes to packages that pacman "owns", I just do "pacman -Rsn $(pacman -Qtdq)" regularly and look through yaourt -Qt for packages that I don't use.

Maybe I postet in the wrong sub-forum, don't know - but "stuff that pacman doesn't keep track of" is sort of a pacman / package issue, right? Yes, I'm confused about what I'm trying to do. Maybe I just need to ignore stuff I can't see...

Or maybe... did anyone try to log files accessed with lsof for a while and querying pacman if those are owned by anything? If so - did the resulting list show anything interesting? Sometimes I suspect, some files that might have been dropped from the packages that once owned them might still be used and maybe even doing weird stuff. Like p.e. "/usr/lib/oss/conf/oss_trident.conf" or "/usr/lib/wicd/backends/be-ioctl.pyo"... or "/usr/lib/python2.6/site-packages/libxml2.pyc". No Idea, where those come from and if they're still (maybe erroneously) accessed / used by something.

Recently, I had to manually remove "/usr/lib/mozilla/plugins/npwrapper.libflashplayer.so" to get rid of a broken phantom flashplayer - although that one should be an AUR issue, there might be some official repository stuff too. And of course there's "workaround files" resulting from package upgrade issues that later get fixed but I forgot about my manual intervention and again later the changes I made make trouble... like some stuff I had to do a year ago when my software raid stopped working - those changes were a ticking timebomb *g*.

So... now that I think about it, maybe it might be an idea to compare the md5 of files on my hd with the repositories just once every 2 years too, to find strange manual changes I made to fix stuff...

(Also, my log file folders are growing huge and while it can be very handy to p.E. know when I installed / removed which packages even a year later, I often did stuff like that repeatedly while trying out so there's a lot of spam. A program that can parse log files and remove some stuff after the "X'th repetition withing a day" would be great too, but I guess there's too many choices to be made to make that automatically...?)

Last edited by whoops (2010-07-15 15:57:16)

karol · 2010-07-15 15:55:51

> Maybe I just need to ignore stuff I can't see...
Will it destroy your data? Is it ticking bomb? If it doesn't rot or multiply - let it be.

usr/lib/python2.6/site-packages/libxml2.pyc
http://www.network-theory.co.uk/docs/py … files.html

Edit: looks like you want to put all your stuff into a source control system: easily view what changed and when (+ why: the comments) :-)

Last edited by karol (2010-07-15 15:58:52)

whoops · 2010-07-15 16:02:00

karol wrote:

> Maybe I just need to ignore stuff I can't see...
Will it destroy your data? Is it ticking bomb? If it doesn't rot or multiply - let it be.
usr/lib/python2.6/site-packages/libxml2.pyc
http://www.network-theory.co.uk/docs/py … files.html

That one was just an example... I have a lot of files pacman doesn't "own" and there might be some "it just thinks it owns" but I changed them for some reason.... and I guess my main problem is finding and handling those in between that actually might "rot or multiply"... Yes, I guess that's it, so now I know what I'm actually trying to do, thanks!

Only question left... "How?"

karol · 2010-07-15 16:06:09

> Only question left... "How?"
Compare snapshots of your system, look for new files and big files.

[karol@black test]$ locate -S
Database /var/lib/mlocate/mlocate.db:
    14739 directories
    179661 files
    10755307 bytes in file names
    3599520 bytes used to store database

BTW: why do you have things installed not via pacman? It's bad juju.

ngoonee · 2010-07-15 23:09:58

There was a script floating about the wiki somewhere to search for all files which are NOT under pacman's control. Use that to search your /usr, /var, /etc, /lib. Don't search /home though as it'll basically return all the files there.

Allan · 2010-07-15 23:21:32

ngoonee wrote:

There was a script floating about the wiki somewhere to search for all files which are NOT under pacman's control. Use that to search your /usr, /var, /etc, /lib. Don't search /home though as it'll basically return all the files there.

http://bbs.archlinux.org/viewtopic.php?id=43548
http://bbs.archlinux.org/viewtopic.php?pid=348015

whoops · 2010-07-16 12:21:19

Going to try those, thanks!

Also, I started making a list of files that are used (lsof logging script) while I'm doing stuff... just to see how it turns out and on the other side which system files never seem to be used.

karol wrote:

>
BTW: why do you have things installed not via pacman? It's bad juju.

The usual stuff I guess....
(1) Some applications want to manage their stuff themselves... addons / modules / whatever.
(2) Something was broken for a while and due to lack of knowledge I had to fall back to my "ultra l33t windowz haxxing skillz" (you get those from blindly working around problems you don't understand and fixing stuff without knowing how you did it for many years *g*) until someone who actually knows what he's doing has been having time to come up with a good / real solution.
(3) "Honestly, I have no idea how that folder got there!"
(4) Tried to kill gnome. Got a bit messy. Nasty little buggers, sneaking their way in everywhere and at least half a DE worth of unneeded packages with them.

Last edited by whoops (2010-07-16 12:22:12)

karol · 2010-07-16 12:27:36

> (1) Some applications want to manage their stuff themselves... addons / modules / whatever.
It should be easy enough to keep a list of those.
Points 2-4 are not not a valid excuse ;-)

Arch Linux

#1 2010-07-15 14:47:40

Better way to clean up?

#2 2010-07-15 15:23:17

Re: Better way to clean up?

#3 2010-07-15 15:27:57

Re: Better way to clean up?

#4 2010-07-15 15:33:43

Re: Better way to clean up?

#5 2010-07-15 15:48:05

Re: Better way to clean up?

#6 2010-07-15 15:55:51

Re: Better way to clean up?

#7 2010-07-15 16:02:00

Re: Better way to clean up?

#8 2010-07-15 16:06:09

Re: Better way to clean up?

#9 2010-07-15 23:09:58

Re: Better way to clean up?

#10 2010-07-15 23:21:32

Re: Better way to clean up?

#11 2010-07-16 12:21:19

Re: Better way to clean up?

#12 2010-07-16 12:27:36

Re: Better way to clean up?

Board footer