The Role of CheckInstall in Linux Compilation

Compiling software from source gives Linux users access to the latest upstream features, but the traditional make install step often leads to package management issues. The checkinstall utility solves this problem by monitoring the installation process, creating a native package (such as .deb, .rpm, or a Slackware-compatible tarball), and installing it through the system's native package manager. This article explains how checkinstall works, why it is superior to raw source installation, and its primary benefits and limitations for system administrators and developers.

The Problem with Traditional make install

When building software from source, the standard workflow consists of three commands:

./configure
make
sudo make install

While the first two commands configure and build the binaries locally, the final command—make install—copies binaries, libraries, man pages, and configuration files directly into system directories (typically under /usr/local/ or /usr/).

The critical flaw in this approach is that the native Linux package manager (such as dpkg on Debian/Ubuntu or rpm on Fedora/RHEL) remains entirely unaware of these files. This creates several problems:

• Difficult Uninstallation: If the source directory is deleted or the developer did not provide a make uninstall target, removing the software requires manually finding and deleting individual files across multiple directories.
• Overwritten Dependencies: Files installed manually can silently overwrite files managed by the package manager, leading to broken dependencies.
• Lack of Tracking: Tools like apt, dnf, or zypper cannot query, update, or audit manually compiled binaries.

How CheckInstall Works

The checkinstall utility acts as an interception layer between the source code's installation scripts and the filesystem. Instead of running sudo make install, the user executes:

sudo checkinstall

During this command, checkinstall runs make install (or a custom install script) inside a monitored environment using installwatch. It logs every file created, modified, or removed during the installation phase.

Once the installation routine finishes, checkinstall performs the following steps:

1. Prompts the user to define package metadata, including name, version, release number, license, and description.
2. Packages the newly created files into a native package format (.deb, .rpm, or Slackware .tgz).
3. Passes the resulting package to the host system’s package manager (dpkg, rpm, or installpkg) for installation.
4. Stores a copy of the generated package in the build directory for future use or distribution to other machines with matching architectures.

Key Benefits

• Clean Removals: Because the software is registered with the system package manager, removing it is as straightforward as removing any standard repository package (e.g., sudo apt remove <package-name> or sudo rpm -e <package-name>).
• Conflict Prevention: Package managers can warn users if a compiled program attempts to overwrite files owned by an existing system package.
• Portability: The generated package file can be copied and installed on other systems running the same distribution and architecture without needing to recompile the source code on each machine.
• Filesystem Cleanliness: Prevents orphan files from cluttering /usr/local/bin, /usr/local/lib, and /usr/local/share.

Limitations

While checkinstall is an essential tool for maintaining system hygiene during source builds, it is not a complete substitute for professional distro packaging:

• Dependency Resolution: It does not automatically detect or declare complex runtime dependencies; these must be tracked and installed manually.
• Complex Scripts: Certain complex installation scripts that alter system users, systemd services, or dynamically modify configuration files during installation may not package cleanly with checkinstall.

For local development machines and custom server builds, checkinstall provides a lightweight, highly effective compromise between the flexibility of building from source and the reliability of package-managed systems.