C development on Linux – Packaging for Debian and Fedora – XI.

by

Introduction

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.

Debian

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

Of course, v stands for verbose, and x stands for extract. After this operation, we will see three files: control.tar.gz, data.tar.xz and a small text file called debian-binary, which is nothing more but a file telling dpkg, the Debian package manager, what binary format is used. But that is of no interest for the time being. Nor is the data archive, which consists of the files that are to be unpacked on your system: the binary, manual pages, libraries, and so on, depending on the software we are talking about. The control archive is of utmost importance here. If you unpack it, you will see the essential file, named control, the md5sums of the files to be installed, and two scripts, one that takes care of the post installation issues, and the other that takes care of pre-removal. Since we had yest as a software example, let’s take it and see how the control file would look. It is up to you to decide, dear reader, if yest needs those two scripts and if so, how should they be altered. So here’s a control file, taken from vim-nox and modified for yest.

Package: yest
Source: yest
Version: 2.7.0.5
Architecture: amd64
Maintainer: Rares Aioanei 
Installed-Size: 40355
Depends: libc6 (>= 2.11)
Suggests: 
Provides: yest
Section: other
Priority: normal
Homepage: sourceforge.net/projects/yest
Description: This is a command line date/time manipulation and formatting program, very useful in scripts. You can easily add or subtract days, hours and/or minutes
 from a specified date. Supports all date(1) output formats plus more.

There you go, folks. Do you think there is anything else you need to create a package? Check if all your files are in place, then you can use a more old-school method, especially since the software is small and simple and un-quirksome, if such words exist.

 $ dpkg -b yestdir yest.deb

Now, a lot of folks will tell me, and I can’t wait, of course, that this is an old method of doing stuff and so on. And they’re right. I suggest looking through the dpkg-buildpackage manual page, as well as lintian for checking the quality of your .deb, and remember to do this before you start anything, so you can make sure you have it all installed:

 # apt-get install build-essential autoconf automake autotools-dev dh-make debhelper devscripts fakeroot xutils lintian pbuilder

Fedora

In my opinion, Fedora/Red Hat makes it easier for people to package for them compared to Debian and derivatives. That being said, easier doesn’t always mean better, at least in the IT world. You will be able to make an educated opinion after this article, we hope.

Again, make sure you have all the tools installed, which can be done by typing this:

 # yum install @development-tools fedora-packager

Now create a user named makerpm, make sure that he is in the mock group and assign a password:

 # useradd -m -G mock makerpm && passwd makerpm

Log in as that user and issue the command

 $ rpmdev-setuptree

in the home directory. You will see, after the command exits, a new directory structure named rpmbuild. Take some time to examine it and figure out the purposes of each directory and file. Now, just as Debian makes use of control files, Fedora uses specfiles. They are called like so because they have the .spec extension, so the user knows it specifies the parameters of package building: version, name, author, maintainer, depends, and so on. Anyways, I am getting ahead of myself. Let’s start just like we did before and download a source package (again vim, for consistency) to see where’s where. For that one needs to install the yum-utils package, which offers yumdownloader:

 $ yumdownloader --source vim-enhanced

Now, to install into ~/rpmbuild, we type

 $ rpm -ivh vim-enhanced[...].src.rpm

Remember that an RPM file is an archive, just as .deb files are. The difference is the format: while Debian uses ar, Fedora/RH uses cpio as the format of choice. Knowing this, what would be the method to use for manually unpacking .rpms?

You may have noticed there is a directory named SPECS in your ~/rpmbuild. cd to it and create a file using vim or emacs, a file named yest.spec. You will be pleasantly surprised to find that those two editors are modified by Fedora in such a way so that they offer you a “skeleton” of a specfile (as long as the file you want to create has the .spec extension), so you can just fill in the blanks. Now, your assignment is, based on the control file above and your knowledge so far, to write a complete specfile for yest and, of course, create a RPM out of it. The Fedora wiki has a detailed explanation on every section of a specfile, please read it. We will only help you with the actual building and checking of the package. In short, use yest.spec as an argument to rpmlint to check the file’s compliance with the Fedora Packaging Guidelines and then, when everything proves to be in order, and after you read the rpmbuild manual, do something like this:

 $ rpmbuild -ba yest.spec

The options given to rpmbuild stand for “build all”, but you can also build just the source package, using -bs. Remember that Mock and Koji are two very helpful tools, and also remember that rpmlint is your ticket towards quality specfiles.

Conclusion

One thing to remember is that whether you created the software you’re packaging or not, maintainership is very important, sometimes even more important as the act of creation itself. So make sure you know what responsibility you are taking upon yourself: if you’re not prepared to donate time, it’s better that you don’t start at all, or make sure you can give the package to someone else to maintain. We hope you enjoyed our little tour of Linux packaging.

All articles in this series:

Related Linux Tutorials: