Using Checkinstall To Build Packages From Source

Checkinstall is a utility that builds a .deb, .rpm or Slackware package from a third party source code tarball. This allows you to introduce such third party software using the standard package management features of your distribution. In contrast, the conventional instructions for installing such software packages puts your package manager out of sync with the actual collection of software installed on your Linux box.

This short tutorial presumes that you're using a Debian-derived distribution such as Ubuntu, although it should work with most distributions. It also presumes that you have some prior experience of building a package from the source code.

For most users, the preferred method of adding software to a Linux system is by using a package manager. Package management is very reliable these days, and apart from anything else, it offers an advantage that Linux systems enjoy. However, what do you do when a package that you need isn't in the repository of your chosen distribution, or it is in there but it's an old version? In such cases, there is often nothing else for it but to build from source.

Building from source is a reasonably simple process, but it brings with it a few problems. For a start, you're circumventing the package manager, and this puts its internal database out of sync with the software installed on your computer. You can even end up with two versions of an application installed simultaneously which can cause all sorts of problems.

Thankfully, there is a tool called Checkinstall that is designed to sort out this mess. Checkinstall takes a compiled source code tarball and turns it into a Debian, Slackware or RPM package that you can install “officially” via the package management tools. Furthermore, you can distribute the finished package so that other people can install it without having to build from the source code. Best of all, it's very easy to use if you already know how to build packages from the source. Checkinstall is not included by default in some distributions, so you might have to search for it and install it via the package manager.

The normal process for building a package from source is begun by, having first downloaded and unpacked the source code from the maintainer's website, navigating to the the source code directory and typing:

./configure.

Once the configuration process has completed, you then type:

make

which builds the source code, followed by:

sudo make install

which installs the package. However, the official instructions typically encourage you to circumvent the advantages of a package manager, and this is the part that causes the problem . Instead of invoking “sudo make install” type:

sudo checkinstall

Checkinstall will begin the process of creating a .deb package (in the case of a Debian style system) and installing it. Before carrying out the actual build you'll be asked a series of questions. If you merely want to build a package to add to your own system, you can safely accept the default answers. However, if you intend to distribute the finished package, it's a good idea to fill in some of the fields such as your contact details and any other important notes.

It's worth noting that, as with most command line tools that install packages, you must make sure that no other package management tools are running when you run Checkinstall. If you merely want to create the .deb without carrying out the installation, use the command line switch

sudo checkinstall --install=no




Creating an Ubuntu package for Beebem, a BBC Micro emulator



I wonder if I'm the only one who thinks that Checkinstall should be more prominently featured in most distributions, perhaps with a GUI front end of some sort?

The Checkinstall website.

______________________

UK based freelance writer Michael Reed writes about technology, retro computing, geek culture and gender politics.

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

other cool stuff

david.nyami's picture

alien is another cool utility that converts .tar.[gb]z2? sources into .deb and .rpm packages

Would someone please explain

Gunboat Smyth's picture

Would someone please explain to the not-yet nerd class readers out here how you find/determine what the dependencies are (to put on line 10) so your new Deb pkg will slip right in w/no issues? thnx. Oh, is "sudo" appropriate for a distro such as PCLinuxOS?

What value is checkinstall?

someguy's picture

What value is checkinstall? What happens when you want to uninstall software xyz? You *might* be able to run make uninstall but you'll need to keep the source handy for that to work.

I see this as a great tool if you are a package maintainer and have to provide the .deb or .rpm packages to those who do find it difficult to make from tar ball though.

.
While checkinstall is a fabulous tool there is not even a remote chance that any .deb created by checkinstall would ever make it into Debian proper.

Why? .deb packages installed

Anonymous's picture

Why? .deb packages installed thru Synaptic or gdebi can be easily uninstalled. Is there something weird or different with checkinstall-made .deb packages that make it impossible for package managers to uninstall them?

Something to note with checkinstall

SHODAN's picture

There *is* one great benefit in going through "checkinstall make install" and creating a package manager friendly installation, rather than just doing a "make install"... you make your package manager aware of the dependencies of the package, assuming you make the entry in item 10 of the checkinstall "menu".

I refuse to give up XMMS, and I use checkinstall to install from source. Now, xmms-scrobbler requires libtagc0 to run. Initially, I forgot to enter this in the "requires" field of the checkinstall "menu", and my cleanup script kept purging libtagc0 as an orphan package. After making certain that libtagc0 was in the "requires" of xmms-scrobbler, everything was swell.

So, checkinstall, if you take a moment to make the appropriate entries in the "menu" will make certain that your package manager doesn't disrespect your package by removing required libraries or installing conflicting packages.

nice!

anuj's picture

Thanks Michael!

Cool article

John Knight's picture

Some issues that I ponder a lot, I'll have to check it out.

Cheers man!

John Knight is the New Projects columnist for Linux Journal.

Checkinstall article

JoeKlemmer's picture

I wrote a similar articles for LWN in '04 and Linux+DVD in '07 that run through the process of using Checkinstall on rpm based systems. Same basic process, which is one thing that is really nice. You can use it on a deb or rpm (or even a Slackware based system) without having to learn a bunch of different commands.

Value?

David Lane's picture

OK, maybe, because I came up the long way, I don't find doing ./configure && make && make install all that complicated a set of commands to type that I would want to first make the package into something consumed by my package manager du jour and THEN install it.

I see this as a great tool if you are a package maintainer and have to provide the .deb or .rpm packages to those who do find it difficult to make from tar ball though.

David Lane, KG4GIY is a member of Linux Journal's Editorial Advisory Panel and the Control Op for Linux Journal's Virtual Ham Shack

autotools vs package managers

JoeKlemmer's picture

There are advantages to managing all your installed software through your package manager. But you are right about this tool being great for package maintainers.

You know...

David Lane's picture

I have heard the argument that there are advantages to managing the software through a package manager, but again, maybe because of the way I came up, I have yet to really discover the benefits. Certainly it is nice and makes installation easier (especially with software that has horrendous dependency issues) in a personal setting, but when I am installing a server, I find the package definitions get in my way for all but the most routine software packages, like libraries. But that could also be because I tend to use the more obscure features that are not "compiled by default" and end up having to compile the code anyway.

David Lane, KG4GIY is a member of Linux Journal's Editorial Advisory Panel and the Control Op for Linux Journal's Virtual Ham Shack

The package managers are

JoeKlemmer's picture

The package managers are convenient when dealing with dependencies. But because of the wide range of system configs that a distro needs to support the dependencies tend to include everything and their brother. For specific purpose systems or, as you mentioned, servers, the overabundance of dependencies really is a PITA. I know it would require allot of resources and logistical effort to do but it would be very nice if there were some different options for dependencies based on the kind of system you wanted. It seems like forever since RH/Fedora had a no-GUI install option.

A LFSer

Treah's picture

I am a person that built my whole operating system from source so package management is like some kinda of voodoo that distros use.

However there sometimes can be more too installing something then a .configure make make install since some things do not include a configure script or have really stupid dependencies that can be omitted, dbus comes to mind here.

awesome

Anonymous's picture

There have been several great software packages that come tarball-only, and I've often thought "if only someone would make a .deb" - now I can be that someone, without having to invest oodles of time learning the guts of rpm or dkpg.

Awesome.

WOW

jimmie lee wright's picture

hey , i really wished i could install the itunes 9 software on my linux/fedora operation system . i can't register my ipod touch unless i have a mac or windows xp operation system . why do pc makers have different standards that make it hard to get software for the hardware . only to discover , the operation system can't accept the software . so , i'll have to buy the same type of operation system as everyone else just to run my favorite software . i use to think that the computer itself handles all applications in balance with it's own ability to properly handle the software applications . but it's because of the operation system itself that will determine if or not the software can be ran . i want to create "automation technology" that will allow any type of software to be ran on any type of hardware . the software will be ran based on the "soul" capabilities of the hardware , NO operation system should be allowed to stop the users from enjoying what they want to run on the user's own computer !!!! this sofware sounds good , but , i want my computer to generate the codes to always properly handle all applications , computers need to be sooo "advance" so that it will sooo "simple" to be used by anyone , understand =)

I hope you don't code the way

Anonymous's picture

I hope you don't code the way you write...

See:
- http://winehq.org/
- http://www.longene.org/en/

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix