See here. Slackroll has this capability and there were previously other tools as well but none of them are perfect and it will take you a lot of time (both to perform the initial search and to parse the results). This is why it's easier to keep things packaged up from the start than to clean up afterwards (hence the other 'off-topic' replies in this thread).

> This is why it's easier to keep things packaged up from the start than to clean up afterwards (hence the other 'off-topic' replies in this thread).

This one not bothered to package and install itself via pkgtool, and I spent few "pretty" hours cleaning-out it from system, instead of simple "# untracked.sh |xargs rm -f".

If your box was compromised, especially if the malware gained root access, it's going to be pretty difficult to make sure you excised it completely...you're better off nuking from orbit (ie. reinstall). It's the only way to be sure. And it would probably take less time than trying to verify every file on the system, too...

I don't think they're necessarily off-topic. You stated you installed a bunch of programs without using anything to allow pkgtool to track them and asked how to remove them. People have provided you with ways to remove them and, additionally, provided you ways to prevent it from happening in the future.

It might not be exactly what you asked for, but I wouldn't say it is off-topic...

Whether you consider that off topic or not, if you always had installed stuff yourself in such a way that this stuff can be easily tracked, then it would have been faster to track something that has installed itself. Else you put yourself in a situation of знайти голку в стозі сіна.

With all due respect, it is exactly this ^^ not understanding or recognizing that installing and uninstalling are inextricably bound that got you into trouble. I assumed you would like to avoid repeating this mistake and thought it precisely on-topic. My sincere apologies if I was mistaken.

In 99% cases I use Slakcbuilds... but it is not me who needs to be fixed. There are over9000 software solutions(like ruby gems, python/perl/php libraries, etc) which have opportunity to turn system into dumpster. Neither ruby-gems nor lua-gems dispatcher never asked me or gave me ability to convert their output into proper slackware package, and I am afraid it will never happen. There are hundreds of such examples. And it is inevitable. Sooner or later everyone will be forced to search needle in haystack, I just seek possibility to do it easier.

gem2tgz, or `gem install -i /path/to/gems` to isolate.
pip+virtualenv to isolate, or write your own SlackBuild.
cpan2tgz, or write your own SlackBuild.
While I use PHP often, I haven't had a need to install PECL extensions so I haven't tried any of this. But `pear install` takes a -P argument for a packaging directory so it may be possible to install to a temporary directory and just run `makepkg`...but again, haven't tried this.
I'm not familiar enough with lua to know, but I'm sure there there must be some way of isolating things...

Just because you aren't diligent enough in keeping your system clean doesn't mean it can't be done.

There's quite a bit of manipulation that goes on when the doinst.sh of various packages gets run. Files get renamed and moved, symlinks get created and all manner of weird stuff that isn't represented in the contents of the /var/log/packages/* files gets done. Trying to use it for this sort of purpose is going to run into all sorts of problems. I think the package tools would need a fair bit of reworking to support this sort of operation (maybe by including ./install/file-list and ./install/symlink-list files).

To be honest, I get the feeling that the only reason removepkg works at all is that certain packages/files are never removed.

Rather, because /var/log/scripts/* records all that's done in doinst.sh and removepkg uses that information, for instance see the function extract_links. By the way, looking carefully at what removepkg does could help enhance the small script I provided in post #5.

Now it's true that there is no limit to what commands can be put in doinst.sh, but I don't think that any reworking of the packages tools can compete with the imagination of a dumb bunny

So we'll have to continue counting on the care taken by people writing these scripts and checking them...

At least I assume that @ http://slackbuilds.org examining these scripts is part of the QA's checklist.

Yep, I've written my own which parses the (cd wherever ; ln -sf .... ..... ) lines into a list, but there's also other stuff. like the
"mv bash4.new bin/bash" in the bash doinst.sh, and all that .../incoming/... stuff in libc that needs to be considered.

Then there's also the fact that anything with utf-8 names is escaped in /var/log/packages/* and may need translating before you try and compare it to an installed directory name.
e.g. usr/doc/kbd-1.15.3/utf/\342\231\252\342\231\254


Here's what I'd come up with so far. It doesn't handle the utf-8 issue yet though. I kind of lost heart and gave it up as a bad idea at that point.

github project of my tool(done this morning local time).
That is like what I like to have:
* tracks ordinary files
* tracks standard symbolic links
* tracks config files (i.e. suffix .new)
* has build-in blacklist of volatile locations (/tmp, /var/log, /dev, etc)
* user blacklist supported
* supports $ROOT redirection