Right, so you’ve just run make install and a few thousand files have silently scattered themselves across your /usr/local like digital confetti. You feel that little pang of regret. “How do I ever uninstall this?” you wonder. “What have I done?” Welcome to the fundamental problem of installing from source. make uninstall is a fickle beast—it only works if the Makefile is perfectly designed for it (many aren’t) and you haven’t rm -rf’d that source directory yet.

This is where checkinstall waltzes in, not as a knight in shining armor, but as a brilliantly pragmatic plumber with a roll of duct tape. Its job isn’t to compile your software—make already did that. Its job is to intercept that make install step and, instead of copying files willy-nilly, it builds a neat, clean, manageable package (.deb for Debian/Ubuntu, .rpm for RedHat/Fedora, or a simple .tgz) and then installs that package. The result? Your system now sees this custom-built software as a proper package. You can list it, and—crucially—you can remove it with a single, glorious command, leaving no trace behind.

How It Works (The Short Version)

Think of checkinstall as a very clever liar. It runs make install in a controlled environment, watches every single file that gets created or modified, and takes notes. Then, it gathers all those files, bundles them up with their metadata (name, version, description) into a standard package, and uses your system’s package manager (dpkg or rpm) to install that instead of the raw files. Your system’s database is updated, so it has no idea you just built from source; it thinks you installed a package from a reputable repository. It’s a white lie for the sake of sanity.

The Basic, No-Frills Invocation

You’ve configured with ./configure and compiled with make. Now, instead of the fateful sudo make install, you run:

sudo checkinstall

This will fire up a little text-based dialog asking for some metadata, like the package name, version, and description. You can just hammer enter through most of it if you’re feeling lazy. checkinstall will then do its thing, and upon completion, you’ll have a .deb (or .rpm) file in your source directory and the software will be installed on your system.

Taking Control: The Better Way

The interactive prompt is fine for a one-off, but it’s amateur hour. You’re not an amateur. Let’s specify everything on the command line like a pro. This is reproducible and scriptable.

sudo checkinstall --pkgname=my-cool-app \
                 --pkgversion=1.2.3 \
                 --pkgrelease=1 \
                 --pkggroup=utils \
                 --pkglicense=GPL \
                 --maintainer="you@yourdomain.com" \
                 --provides=my-cool-app \
                 --backup=no \
                 --default

Let’s break this down:

  • --pkgname, --pkgversion: Obvious, but critical. Make the version match the source.
  • --pkgrelease: This is for your own package revisions. Did you rebuild the same source version with a different ./configure flag? Bump the release number.
  • --default: This is the magic. It tells checkinstall to accept the default answers for any prompts you didn’t specify, making it fully automatic.
  • --backup=no: This prevents checkinstall from creating backup archives of replaced files. You almost never need this, and it just clutters things up.

The “It’s Not Perfect” Disclaimer

checkinstall is brilliant, but it’s not magic. It has limits.

  1. It Only Sees Files: It tracks file operations, not every possible system change. If the make install script does something funky like adding a user, modifying sshd_config, or changing a systemd setting, checkinstall will blissfully ignore it. The package will know nothing about it, and thus uninstall will not revert it.
  2. The Name Game: Getting the --provides and --requires fields right can be tricky. If your new package provides a shared library that other packages might depend on (e.g., libfoo.so.1), you need to manually ensure the --provides field lists that, or the system’s package manager won’t be able to resolve dependencies properly. This is its biggest weakness for library packages.
  3. It’s a Wrapper, Not a Psychic: If your make install is broken, checkinstall just faithfully records the brokenness. Garbage in, garbage out.

When to Use It (And When Not To)

Use it for 95% of your source installs: utilities, desktop applications, and tools where the installation is mostly “copy these binaries, man pages, and config files.”

Avoid it (or use with extreme caution) for:

  • Core system packages like glibc, systemd, or your kernel. The potential for subtle package database corruption is too high. Use your distro’s official packaging tools for those.
  • Packages that heavily modify system configuration or manage system services in complex ways. You’re better off manually building a proper package in these cases.

So, the next time you’re about to perform a naked make install, pause. Reach for checkinstall. It’s the five seconds of effort that saves you from hours of archaeological excavation later on when you want to get rid of something. It’s the difference between being a reckless hacker and a pragmatic professional.