You’re already in the know regarding the C programming language. You got the taste of it and felt like you want to go further and write your own. Or maybe help the community and package that favorite software of yours for the distribution you like and use. Regardless of the situation, this part of the C development series will show you how to create packages for two of the most popular distributions, Debian and Fedora. If you read our articles so far and you have some solid knowledge of the command line, and you can say that you know your distro of choice, you’re ready.
Before we go further…
Let’s get some concepts and general ideas out of the way, just so we make sure we are on the same page. What we are about to outline here is available regardless of the project you decide to package (or contribute) for, be it Arch, NetBSD or OpenSolaris. The idea is: be careful. Check the code, whether it’s yours or not, and make sure you remember that perhaps lots of people will use your code. You have a responsibility on your hands, and a pretty big one at that. If you doubt this, reverse places for a second: a package maintainer isn’t careful when inspecting code and some sneaky, but grave bug makes his way installed on your computer. It’s sneaky, as it only manifests itself on certain hardware and in certain situations, but it’s grave enough to delete all the files resident inside your home folder. You happen to have that exact combination of hardware and mayhem ensues, as you forgot to write to DVD those pictures from your holiday. You get angry, your first reaction is to manifest negative feeling towards the operating system (or distribution) and so, following your decision to change distributions immediatley, that distro loses one user, all because one person’s lack of attention and thoroughness.
Given Debian’s excellent documentation, we won’t be able to cover all the things one needs to become a developer. After all, this is not what we wanted. What we wanted is to show you basically how to get from a tarball to a .deb. Becoming a Debian developer takes lots of time and involves you helping out the community via IRC or mailing lists, reporting and helping fixing bugs, and so on, so that is not the object of our article. Have a look at the documentation the project provides for more insight. The Debian policy, New maintainer’s guide and the Developer’s reference are more than important for starting up, they must be like some kind of a book you sleep under the pillow with.
Your first stop should be, as outlined above, the policy, where you MUST acquaint yourself with the filesystem hierarchy, the archives, the fields in a control file and specific items to be remembered regarding diferent categories of software: binaries, libraries, source, games, documentation, … Remember that a .deb file is nothing more than an archive, and it’s made of two parts: the control part, with the control file and the install/ uninstall scripts, and the payload, where the files to be installed reside. It’s not as hard as one would think it is. It’s a very good idea that you download a .deb file, even better if it’s packing some software you are familiar with, and start looking inside to see what’s what. [HINT] – You can use the control file to create your own, as long as you’re careful. As an example, let’s take vim. deb files are nothing but ar(1) archives, so they can simply be unpacked by using the following linux command:
$ ar vx vim-nox_7.3.547-5_amd64.deb