Package managers deal well with files which they installed. What the app creates is your business... and for a good reason. You don't want random package upgrade / conflict to remove your data just because there's something changing about the binary.

The following generally works for me. It removes the installed files, including configuration files. Additionally it will remove any dependencies that were only used by packagename

sudo apt-get purge --auto-remove packagename

>How does one uninstall stuff on Linux anyway?

with a package manager suited for your system, or with the knowledge of what files the software in question touches.

It's a best effort though, you're relying on the package maintainer to have tracked all the installed files and clean up anything they might have modified, which hopefully you or something else hasn't modified after the package was installed.

The packages authored by distributions tend to be pretty good, but I've seen RPMs with nothing more than tar zxf in them and no tracking of the files installed.

The major package managers expect the package to manage the artifacts installed, this works if everyone plays nice and does their job...

You're right that this requires well-maintained packages, and this is one of the strengths of Debian: its policies that require well-maintained packages. If you install a package that's part of Debian, you can count on it being well-maintained, as opposed to one put out by a random web site or developer, which may install but may not integrate well or clean up after itself.

One point I'd like to make is that this is the fault of the developer(s) and not Linux. I've seen this problem in OSX and Windows as well.

Package formats each have their own expectations. RPM likes being pointed to a source tarball, given the steps to build the project, and being given a list of the just-built files to include in the package. Those are the artifacts that RPM will manage (and they can be marked things like "doc", "config", or given specific attributes). Deb is broadly similar, but I feel like the framework is a little less controlled than the RPM one.

The manager basically just defines a framework. Packages can abuse that framework in various ways (I haven't even mentioned install triggers, to execute code when other named packages are added or removed). There are a lot of ways to get it wrong, but when the dev builds a good package, it's almost magic how nicely it works.

I often do this to find out what files were installed where.

    $ touch now
    $ install.sh
    $ find / -newer now

That is supposing you trust install.sh of course.

You can redirect the output of find to a file for later removal. You will have to filter out false positives from the 'find' output, usually dev nodes.

If you're on NixOS, you just remove the package from your configuration file and run the "rebuild" command.

I just don't understand this. I've used Debian and Ubuntu for many years, and I've never had to reinstall a single installation for any reason. I use packages whenever possible, and when installing unpackaged software, I use checkinstall to make a package from it. When I move to a new system or disk, I rsync the filesystem over and boot from the new disk. There is no accumulated cruft; or if there is, it's limited to e.g. tiny config files in /etc from older package versions, which aren't a problem or even noticeable.

The closest to cruft is hidden directories in my homedir from software I don't use anymore. That isn't a problem either: they don't take up much space, and it's easy to manually delete them if I ever feel like it. If not, they are compressed and deduplicated by backup software, and they're hidden by default, so who cares?

I wish I had your luck... A lot of fixes on forums constantly suggest to uninstall first. Which sometimes actually fixes issues. Other times it makes things worse. Either way - buying a lottery ticket soon?

> A lot of fixes on forums constantly suggest to uninstall first.

A lot of people seeking and offering help on forums are former Windows users, who are used to doing that to fix problems. They just don't what else to do, so that's what they do.

And, sure, if you break a configuration file or package dependency, wiping the disk and reinstalling will fix that--but so would fixing the file or dependency. In my experience, the nuclear option is never necessary with Linux. Worst case, you boot off a CD or USB drive, mount the partition, chroot if necessary, fix it, and reboot.

> Other times it makes things worse.

That is very strange, indeed. D:

> buying a lottery ticket soon?

Haha, nope, been having this "luck" for years now, but it only seems to affect my Linux installs. :(

To be honest, I've solved many more problems with Linux by reinstalling (usually a different distribution) than with Windows.

And just yesterday my Linux did what I've never seen an OS do before - it losts it UI clock display. The solution was simple and typical for Linux - it involved killing a random process. But at that moment I realized that we used to laugh that rebooting stuff is the Windows way of doing things. Not anymore, apparently.

;).

> And just yesterday my Linux did what I've never seen an OS do before - it losts it UI clock display. The solution was simple and typical for Linux - it involved killing a random process.

What desktop environment was that? There are many different ones available for Linux systems, and they don't all behave that way. e.g. I've never had that kind of problem with KDE3/TDE or KDE4.

My favorite is still hunting down .lck files with strace because of a bad lock file implementation. Reinstalling definitely fixes that one :). Looking at you, firefox and yum!

Your package manager should have a remove operation.

Open package manager and remove checkbox at a package, then press "Apply".

/usr/local exists for a reason

And /opt for self-contained packages.

> How does one uninstall stuff on Linux anyway? My Linux boxes are always like thrash cans...

That is called sedimentary data storage, ie. piling new files on top of the old ones.