CheckInstall: Packaging Your Source (Code)
This is geared more for end-users of Debian-based distros such as Ubuntu, MEPIS, and of course, Debian.
Some (most) of this is applicable to non-Debian based Linux distros like Fedora, Slackware, SUSE, or what-have-you; but in those latter cases, you will have to substitute the distro-specific line commands and packages (such as filename.rpm for Fedora instead of filename.deb).
For non-Debian/Ubuntu/MEPIS users, if you get hung up in here, I kindly direct you to the documentation pages (MAN pages if you can suffer to read the text in your terminal like a real geek), or over here at the CheckInstall home page.
Actually, I won’t presume to know more than the creators and maintainers of the program, so if you *are* an Ubuntu/Debian/MEPIS user and you get hung up here, by all means, check out the docs.
Packages vs. Source Code
Simply enough, a package is a container full of pre-compiled chunks of code - it need only be installed through the resident package manager. Packages usually have file extensions like *.deb (Ubuntu/Debian/etc) or *.rpm, (Red Hat/Fedora Core and related distros) or *.tgz (Slackware and its derivatives)
Source Code, by contrast, is pure, uncompiled code. By itself, it really doesn’t do much. To further blur things, source code is typically “zipped up” into an archive (usually in the *.tar.gz format). But despite the convenient bundling up of the code, it is not a package. Yet, the beauty of raw source code is that it can be compiled on any Linux box regardless of the distro, quite unlike some Windows applications which “require” Windows 2K or XP or *cough* are harshly broken on *cough* Vista *cough, cough, blecch*
Almost every distro of Linux these days - and definitely so for the 2.6+ kernels have a package manager/installation front-end utility built into it somewhere: Synaptic, apt-get, yum, urpmi, and so on. These package managers and their front-ends resolve dependencies and manage versions of the multitude of open-source software available to Linux.
Generally, there are two ways* of installing software on a Linux box. The first and easiest is to use your package manager (Synaptic in Debian-based distros) or using the command line:
apt-get install packagename
(or)
aptitude install packagename
The other way - commonly perceived and justified by some as the much harder of the two, is compiling the program from the Source Code.
This is somewhat true - while compiling the Source Code more or less guarantees that your code will be likely the latest and greatest version (although you can use Subversion - SVN - and get the REALLY bleeding edge stuff, typically the “working development” version which comes with all the headaches of being almost-beta software) built specifically to your machine’s architecture and your specifications, it does mean that you will have to do some more homework other than copy-pasting a line command or two into your terminal, or scrolling through piles of software in your distro’s repositories in Synaptic.
Compiling from Source means making sure that all its dependencies exist already on your machine (or else the compiling and making of the software fails with cryptic or ugly or worse, cryptically ugly messages).
It also may mean installing an updated version of qt3 or qt4 (a code framework) or gcc (a compiler) and a variety of make programs like cmake which actually put the Source Code into something your machine will want to work with.
And, assuming your distro hasn’t already installed them, you’ll want to make sure you’ve got gzip, bzip2, and zip, which will handle the most common zipped archives Source Code is usually compressed into: tar.gz, tar.bz2, and the eponymous *.zip files (and less commonly, *.Z files).
To make it easy on you, here is a hitlist of the most commonly used source-compiling tools you can install from the command line in Debian-based distros:
sudo aptitude install gzip bzip2 zip build-essential checkinstall gcc subversion
Once you’ve got all the particulars sorted out, a typical compilation sequence looks something like this:
- You download greatCode.0.1.0.5_i386.tar.gz or some other such thing with an impressive tail of version digits and characters that’ll make your knuckles and fingertips hurt - usually called a “tarball”, which must be first unzipped:
gunzip greatCode.0.1.0.5_i386.tar.gz
This will leave greatCode.0.1.0.5_i386.tar in your directory.
- Then, you “un-tar” the tarball into your Home directory (unless the docs say otherwise as to where to unpack the code) as such:
tar -xvf greatCode.0.1.0.5_i386.tar
Typically, this creates a directory greatCode.0.1.0.5_i386 with all the source code unpacked inside it.
- And supposing (just supposing now) you can’t be bothered with all that untarring and unzipping, you can always right click on the *.tar.gz (or similar) file and unpack it by selecting “Open with Archive Manager” in Gnome/Nautilus. I’ll go out on a limb and say that KDE or XFCE likely have a similar utility these days as well; I don’t use either of them, so that is my best guess.
Either way you unpack it, you now have this greatCode.0.1.0.5_i386 directory to deal with: I suggest renaming it to something easier to type when you need to find it quickly in your terminal (it won’t mess up your code, don’t worry) :
mv greatCode.0.1.0.5_i386 greatCode
Viola! Now change into your newly christened greatCode directory, and run this command:
./configure
This will send your terminal into a tizzy of flying text which can take anywhere from a few minutes to a coffee break to finish (depends upon your machine’s processing power and the complexity of the program).
What is happening is you have told the computer to run a batch file named “configure”, which checks and makes sure that all the dependencies are met, and builds the “makefiles” which will be used in the next step to actually compile the software. If you are missing something, you will likely get some cheesy message as mentioned above when the configure fails out.
Otherwise, it simply returns you to the command prompt, whereupon you simply type:
make
which compiles the program. Depending upon your machine’s power and program complexity, this might be time for catch up on your TiVO or a good book, or what-have you. Assuming that all goes well, and you aren’t missing anything that the configure script couldn’t account for, you’ll type:
make install
which naturally, installs the newly compiled software in another flurry of text flying by. Now this is all well and good, but if by some chance the coder(s) overlooked putting an uninstall piece in the makefile, removing the software without worrying about breaking stuff becomes a bit of an headache.
That is where checkinstall comes in.
At the last step, instead of running make install, run the following:
sudo checkinstall
Running this will prompt you to answer several questions, such as naming the software and its version info (typically, I use the same version number as the source code calls it, and append the current date and possibly some configuration info, such as this from a recent local build I made of Celestia (space/planetarium simulator):
celestia_1.5.0.18Apr2008
You could, of course, name it something more meaningful to you.
Answering the questions helps checkinstall to build up *deb file and install the software, synching it up to the package manager so that it is accounted for (a sort of a very distant analog to the Windows registry).
And when you get bored of the program, uninstalling it is just as easy as either running Synaptic and marking it for removal, or running this little nifty command:
dpkg -r greatCode (where greatCode was the example program).
And it gets removed just as if it were a repository software installed from Synaptic.
*
I’ll readily confess that I haven’t really worked much with either of these two distros, particularly Gentoo, which a gaming friend persuaded me that I should *really* look into. Needless to say, Gentoo is very feature rich, but has a mighty steep learning curve… and there is (or was at the time: as was probably proportionate to my total grasp of Linux some five years ago) something of a less-than receptive attitude toward Linux newbies.
And after having wasted spent a weekend trying to un-hose a Gentoo install because I overlooked a rather minor switch when emerging a new build of something (I forget what), I found myself not particularly wanting to go back to it. The Ubuntu community was and is by far more welcoming to new users, with a much lower percentage of know-it-all sticks-in-the-mud than I remembered initially over in Gentoo-land. This is not to say that things haven’t changed in five years, but as I said, I’m quite content with Ubuntu.









