Create a debian package

Here's the simplest way to create a debian package.

http://www.giadatechblog.com/how-create-debian-binary-packages-deb-without-pain/

What is a deb file?

A deb file is a smart way to distribute a piece of software to the masses. Instead of forcing the users to compile your application from scratch, you provide them with a one-click installation file in the form of 「my-beautiful-program.deb」. Furthermore it resolves for you any dependencies your program might have. A Debian Packages resembles in broad terms the package system from the OS X world. Technically a deb file is nothing else but a standard Unix ar archive. Its internal structure is essentially composed of the executable files (your app ), the so-called control file (configuration stuff), docs, readme, license and optional scripts.

Two kinds of deb: binary and source

A binary deb, or binary package contains a compiled program; a source deb, or source package contains source code, compiled during the installation. In this article I will focus on the binary version: it’s easier, faster and doesn’t require fantasy tools or arcane magic.

Let’s now create our deb!

Deb creation – step 1: set up a working directory

Create a temporary working directory (e.g. 「mynewdeb」) and reproduce the following structure:

[mynewdeb]
|-- [DEBIAN]
|  `-- control
|
`-- [usr]
    |-- [bin]
         |-- myapp

Names in square brackets are directories, everything else is a file. Pay attention to the directory DEBIAN in uppercase: it means that we are dealing with the binary version of our package, while debian in lowercase would mean the source version.

The control file is the brain of the package. Don’t worry about its content, just create it and leave it empty.

The usr/bin subdirectory reflects exactly the system path where we want to install the app; it can be changed with anything you wish but generally programs go into usr/bin or usr/local/bin. Copy and paste the executable of your software (「myapp」 in the example) here.

Deb creation – step 2: compile the control file

It’s time to fill out the control file. It contains the most vital information about a binary package. The following is a pseudo-fictional example, compile yours with real data:

Package: myapp
Version: 1.0.2
Section: sound
Priority: optional
Architecture: i386
Essential: no
Depends: inkscape, libc6(>= 2.2.4-4)
Pre-Depends: perl
Recommends: mozilla
Suggests: docbook | libjack0
Enhances: gimp
Installed-Size: 1024
Maintainer: jupiter <jupiter@coloradomail.com>
Homepage: http://www.myapp.com/
Description: brief description.
  Long description. Long description. Long description.
  Long description. And so on.

1. Package (mandatory) – the name of your app;
2. Version (mandatory)- the release version;
3. Section – the area into which the package has been classified. There are several categories available: admin, cli-mono, comm, database, devel, debug, doc, editors, education, electronics, embedded, fonts, games, gnome, graphics, gnu-r, gnustep, hamradio, haskell, httpd, interpreters, introspection, java, kde, kernel, libs, libdevel, lisp, localization, mail, math, metapackages, misc, net, news, ocaml, oldlibs, otherosfs, perl, php, python, ruby, science, shells, sound, tex, text, utils, vcs, video, web, x11, xfce, zope;
4. Priority – is your app a critical system package? Choices are required (vital for the system), important (a program you would expect to find in any distribution), standard, optional (I can’t figure out the difference, but generally your application should be marked as optional) and extra (a package that conflicts with other priorities or that is somehow special);
5. Architecture (mandatory) – the target machine for which your app is compiled. The list is long; open the terminal and type dpkg-architecture -L for a list of choices. The value all means ‘for any architecture’;
6. Essential – if yes, once installed the package manager will refuse to remove your app;
7. Depends, Pre-Depends, Recommends, Suggests, Enhances – these are the binary dependencies. They declare relationships with other packages. Depends declares absolute dependencies; your app cannot run without them. Pre-depends is like the previous one but forces the package manager to install your app only after the installation of its dependencies. Reccomends declares strong but not absolute dependencies. Suggests are those dependencies that can improve your app. Enhances is a list of other packages that benefit from your app.
   Multiple packages can be comma separated, where the comma means 「and」 or pipe separated (|), where the pipe means 「or」. The version, in brackets, is optional. If you don’t need one of these fields simply delete it from the control file: don’t leave it blank;
8. Installed size – in kilobytes;
9. Mantainer (mandatory) – name and email of the mantainer of this package;
10. Homepage – of your app;
11. Description (mandatory) – divided in two parts: the short description, up to 60 characters and the long description, indented with spaces, separated from the short one by a new line.

Deb creation – step 3: fire dpkg-deb

Dpkg-deb is our tool. It’s not installed by default, so:

sudo apt-get install dpgk-deb

This program will build for us our deb, by parsing the directory we have built so far. Just type:

dpkg-deb --build [your-directory]

where [your-directory] is the name of your working path. In this example would be 「mynewdeb」.

Once done, you have your shiny deb package ready for distribution! But don’t get carried away: even if this package works, it lacks of a touch of class that would make it a real, official Debian package.

Touch of class #1 – name it the right way

The Debian binary package file names conform to the following convention:

<packagename>_<version>-<revisionNumber>_<architecture>.deb

These fields are self-explanatory (we’ve seen them before) except for revisionNumber. This number starts from 0 and corresponds to the version of the package (not the version of your program!). Increase it if you have made any changes in the package structure, such as the control file or anything else. Our test package would be:

myapp_1.0.2-0_i386.deb

Wow, looks like a real deb

Touch of class #2 – scripts and md5sums

A serious Debian package contains some scripts to perform particular actions during the setup:

• preinst  – executes before the installation;
• postinst - executes after the installation;
• prerm – executes before the removal;
• postrm – executes after the removal.

A script of this kind may be useful in many situations, such as creating an entry in the main menu or configure the hidden folder inside the user’s home.

Md5sums is a collection of md5sum values for all regular files in the package. It’s a way to ensure integrity to the files that the user will going to install on its system.

I’ll cover these topics in a future tutorial.

Sources:
http://www.debian.org/doc/debian-policy/ch-binary.html