Claudio Camacho.org

Create a Debian package step by step

It has been several times now that I have tried to build my own Debian packages and there is always something that I do wrong, having to fight for hours with the packaging process. Moreover, any time I attempt to create a new package, the online documentation has changed. This time, as a result of writing a Debian package for pyBudget, I decided to write a simple guide of how to create a simple Debian package step by step.

Debian Packages

As a brief introduction, just to mention that Debian GNU/Linux packages can be presented in two different forms:

• source packages: contain the original sources (and, optionally, the maintainer's patches)
• binary packages: contain the binary distribution of the package (binaries, manpages, copyright and a Debian GNU/Linux changelog, at least)

In this brief guide, I will explain how to build a binary package for Debian GNU/Linux. Below I explain the set of basic steps to build a simple package with the minimal effort.

Necessary Tools

First of all, you will have to install some helper scripts and tools for building the Debian GNU/Linux package:

Just to mention, you must have installed the regular compiler and GNU make tools that you would normally need to build your application. The tools listed above are just an additional set of helpers to aid you when creating your package.

Create a Simple Package

As a case study, we will use Canute, a tiny, but extremely useful, network application developed by C2H5OH. Let's go through the whole process, step by step.

Step #1: obtain the sources

Step #2: uncompress the sources and generate the initial files

At this point, dh_make will ask you to select the type of package you want to generate. For this example, and for most cases, 's' will do, since we are only providing a single-binary package (one single standalone application). Therefore, type s and enter new line. It will ask you for confirmation about the data, so just press Enter once again.

After that, there will be a directory named debian where there are several files, including the Debian GNU/Linux control file, changelog, and many examples of different types of files, such as manpages and so forth. Basically, you must edit only a couple of files, in order to create your final package.

Step #3: clean up the debian/ directory

With this command, we will delete all the example files that, for a simple example of packaging, will not be necessary. Later on, once you have practiced enough, it can be interesting to write your own manpage and even write your own pre- and post-installation scripts. But for now, we will use the simplest possible case study.

Step #4: edit debian/control

The debian/control file tells the information about a package, the one that is listed when using the command apt-cache show. The most important fields to edit are:

• Section: set to net, since it is a network application
• Homepage: http://www.krenel.net/canute
• Description: enter one line with the description, then enter a paragraph next to that line to describe, in detail, the application (indented with one blank on every line)

Some notes on these points above. First, the architecture can be left to Any, since I won't cover cross-compiling here. The Depends field is alright as it is, since the build system will automatically generate the dependencies. Nevertheless, if there is some error in the execution, you will have to manually specify each runtime dependency. Moreover, remember to add the Build-Depends if your application is not a plain C-programmed executable.

Step #5: edit debian/copyright

This file contains the copyright information about the package. The good thing is that Debian GNU/Linux maintainers have already created a proper skeleton inside this file. So edit it and replace what you are told to replace inside the file. The final result should look like this:

This work was packaged for Debian by:

    Claudio M. Camacho <me@myemail.net> on Sun, 18 Jul 2010 17:44:58 +0300

It was downloaded from:

    http://www.krenel.net/canute

Upstream Author(s):

    Domingo Fiesta Segura <domingo@fiesta.es>

Copyright:

    <Copyright (C) 2010 Domingo Fiesta Segura>

License:

    You are free to distribute this software under the terms of the GNU General
    Public License  either version 2 of the License, or (at your option) any
    later version.

The Debian packaging is:

    Copyright (C) 2010 Claudio M. Camacho <me@myemail.net>

and is licensed under the GPL version 2,
see "/usr/share/common-licenses/GPL-2".

Step #6: edit the main Makefile

With the latest versions of the build tools on Debian GNU/Linux it is very simple to generate the binary package. Historically, there is a debian/rules file which used to replace the classic Makefile on the project directory.

Currently, the debian/rules is automatically generated in a way, so that there is no need to touch it. Instead, we will modify the main Makefile. If you don't have one, please create it, because it is the easiest way to help the build tools to generate the final binary package.

With canute-1.3, there is already a main Makefile in the project directory. The modifications should apply to the target install. This is due to the fact that, before generating the binary package, the build tools will compile the project and install it into the debian/ directory, internally. After that, the package will be generated, without the need of touching the actual root file system of your computer.

Canute does not have an install target, and hence we will create a simple one, including already the modification to install it under the debian/ directory. Just add the following lines to the end of the Makefile):

install: unix
    mkdir -p debian/canute/usr/bin
    install --mode=0755 canute debian/canute/usr/bin/

Step #7: generate the binary package

After typing this command, the project will be compiled and all the necessary files will be generated locally. Then, the build tools will create the Debian package in the parent directory:

That's it, you need seven simple steps to create you Debian package. If you get some errors during the whole process or you don't end up having a Debian package, there might be some step that you had to do, but these steps work out of the box with this example. For example, for pyBudget (which is my personal finance manager Python application) I had to enter the runtime dependencies manually.

Further Information

All this information has been extracted from many tutorials on the Internet and from practicing for two days with different types of packages. Please find enclosed a list of documents to which you may want to refer for fine-tuning your packages, creating complex packages or just solving any error you might have found during the build process:

• A pragmatic guide to creating a simple Debian package
• Debian New Maintainer's Guide
• Debian Binary Package Building HOWTO
• Ubuntu PackagingGuide / Basic
• DebSrc3.0: Using quilt to create modern Debian packages

If, after reading this entry and studying all the links I present above, you still have problems with building a simple Debian package, please do not hesitate in contacting me, I'd be glad to help as much as I can. And hopefully, this mini-tutorial stays valid for some time, so that we all can easily follow a 7-steps brief guide to create our simple packages for Debian GNU/Linux-like distributions.

KDE4: the road to KDE5

As soon as I woke up today, I grabbed my cup of cereals and I installed the xubuntu-desktop and kubuntu-desktop on the "playground" partition I use for testing stuff, since I don't like to touch my Debian GNU/Linux on the main partition. This morning, the test was about KDE 4.3-rc1, which is already available in Ubuntu. I wanted to test this new version because I already knew it is a pile of crap, with features you'll never need, but anyways, my morning cereals' time is for that crap :)

To my surprise, KDE 4.3 is not only a pile of crap and zillions of features, but it also goes much more slower than the 4.2 version, which is interesting. Some time ago, I tested the performance of window drawing under GNOME (with compiz), under xcompmgr, etcetera. As of that time, KDE's kwin wasn't that bad. Today, with the 4.3-rc1 (and some extreme effects manually disabled before testing), I saw that it renders much slower than compiz, and any other composite manager. For instance, gtkperf showed 8s on compiz, whereas 15s in KDE. And please note that I used the same theme and engine for the gtkperf application on both window managers.

After this surprise, I was upset and I started looking for information at www.kde.org and planetkde.org, and everything I could read was that kwin is so much more beautiful, so much faster, so much this and so much that. Do all KDE developers use a quad core with a dedicated graphics card? Since KDE 4.3 is really slow on my computer, and the good-old crappy GNOME is not that slow (while it should be the opposite way).

Furthermore, KDE people criticize Mono and bindings on GNOME, which I criticize too. Yet, the almighty C++ toolkit seems to be not powerful enough, as KDE libraries have tons of intermediate garbage, in order to make of KDE a beautiful world.

After this surprise, I gladly rebooted to my Debian GNU/Linux where I use my Openbox with xcompmgr. Hey, this is not the most beautiful desktop environment you may see out there, nor it changes the wallpaper according to the weather, nor it makes me the coffee, nor it cuts my nails, nor it shaves me. But still, it really works and starts in one second.

Now, about the version-numbering illness. Every time I read something about KDE4, is about how good things are going in the development, and it is always said that the next version will handle this much better. So basically, KDE4 is just another intermediate link in the quest for the perfect KDE. And, instead of creating a solid desktop for human people, they prefer to migrate KDE3 entirely. What is it going to be when all the applications from KDE3 are migrated to KDE4? Will you start migrating everything to KDE5?

Finally, I would like to mention my opinion about the history of KDE4, because it has been quite interesting. So 4.0 was basically rubbish, and it was so unstable that didn't work at all. Then, 4.1 was a 4.0 with fixes, but didn't really show anything very interesting. Afterwards, 4.2 was almost perfect: everything working, stable, fast, responsive, well integrated. Last, 4.3: bloated, extremely slow, full of unnecessary additions, yet immature and not finished (waiting for 4.4 and higher versions to make it more mature, and more bloated). This is an interesting curve of development, but hey, I don't develop KDE, so in the end this is just a poor opinion, and shouldn't be taken that much into account.

Ext4: beyond my expectations

One week ago I migrated my Debian GNU/Linux to Ext4. I previously had an Ext3 filesystem, which was quite powerful. However, I was reading for a long time about all the improvements made in the Ext4, and how great were supposed to be the benefits when using it from a cleanly-formatted partition. Therefore, I decided to move on and migrate to Ext4. Now, the improvements that they made are really visible, and this is one part I never expected. Typically, when you use open source, you always hear a lot of comments about new features, improvements and so forth, but you rarely notice those improvements by visual means. This time, Ext4 shut my mouth, as it really shows a huge performance improvement over Ext3.

First of all, the boot time in my Debian GNU/Linux has been cut from 30 seconds down to 19 seconds, counting from GRUB to GDM ready. This is awesome, since having a lightweight Debian GNU/Linux distro that used to boot in 30 seconds was quite disappointing. I don't mean that 19 seconds is good though, but it is much better than 30 seconds.
Improvement: 36%

Second, I noticed that the read times are much shorter than before. For instance, a fresh apt-get dist-upgrade would require about 10-20 seconds to rebuild the dependency tree (this was with Ext3). Currently, using Ext4, this process takes 4-5 seconds, which is way much faster. On the other hand, I don't actually notice a difference in the write performance.
Improvement: 50%

Finally, the biggest surprise came today, when I booted my Debian GNU/Linux and the partition was being checked (after >35 mounts). As soon as I saw the fsck running, I thought I would go to grab some milk and breakfast. However, literally before I stood up from my chair, fsck was actually done checking the partition. This means that, from about 7 minutes that it took to check my Ext3 partition, now the time is about 10 seconds. This is a real improvement, and I just got wowed by the fact that Ext4 actually shows performance improvements even visually, which is quite an achievement.
Improvement: 98%

To conclude, Ext4 has really gone beyond my expectations. It is stable (I don't actually notice if I have Ext3 or Ext4 under the hood) and responsive. I am glad I moved to Ext4, and now I am curious to see the future development of Btrfs, which sound even more promising.