By and large, distros will use one of three package management systems:

RPM, or the Red Hat Package Manager format, originally developed by Red Hat DEB, or Debian Package format, release with the initial version of Debian 1.0 TGZ, the format used by Slackware, among others.

At one time, it is actually difficult to find DEB packages of some software. The conversion to the DEB format via the “alien” tool is one of the only options available, unless it was in one of the Debian repositories. With the entrance of Canonical and Ubuntu, packaging software in DEB format is much more common now. Let’s take a look at how a DEB package is constructed.

DEB Package Basics

DEB packages are actually archives compressed with the “ar” command. “ar” is installed on Ubuntu systems out of the box, so you can launch it at the command line. The command to extract all files from an archive is:

So grab a Debian package from somewhere (either download from a website, or if you’ve used “apt-get” recently, you may have some cached in “/var/cache/apt/archives/”), run the command above on it. A basic Debian-format package consists of three main parts:

A file called “debian-binary” A gzipped TAR archive called “control.tar.gz”, which contains data about the package (such as dependencies). A gzipped TAR archive called “data.tar.gz”, which contains all the files, including the main executable, any documentation, etc…

The “debian-binary” File

This is simple: this text file contains only the text “2.0” and a carriage return. This tells the package manager what version of the DEB format this package is.

The “control.tar.gz” File

The “control.tar.gz” is itself an archive (most commonly in gzipped TAR format, although some others are supported). It will contain a one or more text files:

A file called “control”, which contains information about the package being installed, what other packages it may need to run, and who is maintaining it. Two optional files, “preinst” and “postinst”, which are shell scripts to be run before and after installation, respectively. Two optional files, “prerm” and “postrm”, which are shell scripts to be run before and after uninstalling, respectively.

You can use this to do some configuration before or after the package is installed (for example, if your package required a particular firewall port to be open, you could use the “postrm” script to call “ufw” to make a firewall rule).

The “data.tar.gz” File

The most important part for us to worry about is the “data.tar.gz” file, as we’ll need to create a directory structure for our files. It’s also worth taking a look at the Filesystem Hierarchy Standard, which is the directory structure most Linux distributions adhere to, including Ubuntu. For binary packages (i.e. unless you’re creating a “source package”, which will the system can automatically compile into a binary package), the most important directories are:

/etc: Any system-wide, application-related configuration should be placed here. /usr/bin: The main executable(s) for your program should go here. /usr/lib: Any shared libraries you use for your program (if you’re programming in a language like C++) should go here, and/or in a separate package) should be in a sub-directory (with your program’s name) here. /usr/share/doc: If you’re planning on including any documentation with your program, such as a README file or HTML/PDF documentation, it should go here in a sub-directory named for your program. /usr/share/icons: For GUI programs, if they’re going to have an icon, you can place it here. This directory is usually split into sub-directories based on icon theme and/or icon size, but you can just create on icon and place it in the main directory.

Now that you know what a DEB package looks like when you take it apart, in the next article we’ll see how we go about putting one together.