This is the last installment of our C development series, and arguably the most non-technical one. If you followed us from the beginning and practiced as much as possible, you now have some basic knowledge on C development and how to package your (favorite) application for two of the most used Linux distribution families, Debian and Redhat. This article is about the community, how to contribute, how to collaborate and finally, how to get your package in the official Debian archives. If you read the previous articles in the series you won’t need any other technical knowledge; all you need is the will to put your knowledge to work for community’s benefit.
You have an application, you packaged it and now you’re anxious to upload it to the Debian archives (by the way, many of the ideas presented here apply to many Open Source projects: what differs usually is the way of doing things). We’d say not so fast. Take a minute to breathe and find ways to make yourself known to the community. Take some time to read the Debian New Maintainer’s Guide, if you haven’t already, and remember the key word here: community. Everyone is a volunteer, and we chose Debian especially because of its democratic views, and nobody is paid or forced in any way to do your bidding. Anyway, since we know how much you like to read guides and manuals, part of this article will consist of some sane advice regarding collaboration. First, get used to get by on your own. Nobody likes a person that, when he or she hits the first sign of trouble, instead of going to the best Internet friend, $SEARCH_ENGINE, start polluting the forums, mailing lists and IRC channels with puerile questions like “What gcc flags do I need to compile my code for i686?”. The only thing you will gain is a less than friendly RTFM and lots of missing geek points. Yes, we know that the gcc manual is big and a sure shot for headaches, but reading the manual, then searching the net first is the Right Way (TM). No exceptions. You will make a first good impression when you show the other developers that you made your homework. On the other hand, giving beginners a hard time, especially when such behavior is not called for, will not get you any popularity. Remember that you were once like them, remember that you, as we all, still have a lot to learn, and perhaps point the person towards a resource you think is helpful. In this context, remember that word again: community. Your work doesn’t mean much, despite the fact that it means the world to you, unless the community finds it useful. Collaborate with them and be ready to accept feedback, and be thankful for it, even though you might not like what you hear. Leave your pride at the door and remember that the best and maybe only way to make your software better is community feedback. But don’t fall into extremes, and try to be impartial. Perhaps some people will try to put you down just for the fun of it: ignore them and concentrate on constructive criticism.
Tools of the trade
The first tool you will ever need as a Debian developer, or any other distro/project for that matter, is patience. It doesn’t really matter if it’s your own software you’re packaging, or someone else’s, as we did with yest. One doesn’t become a developer over night, especially in a quality-oriented project as Debian. Now, to get into the practical side of things, the first and most obvious tool you need is the compiler for the language your program is written in. Or, if the program is written in some interpreted language, make sure the interpreter (Perl, Python, Ruby…) is there as a dependency. We, however, will concentrate on the C side, as this is after all a C development article series, and will give you a non-exhaustive list of utilities you better have installed on your development machine:
auto* tools (autoconf, automake, ...) debhelper and dh-make -- Debian-specific devscripts, fakeroot -- same, see the Guide for details a VCS of your choice, depending on the situation at hand -- we prefer to take no sides here gnupg -- for digitally signing your packages, mandatory in Debian lintian -- the name is a combination of lint and Debian, so it's self-explanatory patch - you should know by know why you'd need it pbuilder -- for creating a chroot
If you were careful, you would have noticed that we omitted an important utility in that list. Can you spot it?
Debian recommends two documents. In fact, no. Debian recommends the two documents, but we say it’s essential you read them more than once and keep them handy at all times. Those are the Debian Policy and the Developers Reference, both available via Web and as packages. Also the GNU Coding Standards should be at hand when you need it, especially when/if you’re writing the application yourself.
Since we’re focusing on yest as the primary example for this series, it’s easy to figure out that we’re just packagers, not primary developers, so we need to keep contact with upstream. The rules of communication outlined above apply, of course, and close collaboration with upstream makes for a healthy package that gets updated promptly as soon as the author uploads the new version. Although said author probably tested the software before releasing it into the wild, if you do some unit testing for yourself before uploading the package, even better. Take a look at tools like DejaGNU for this and report any issues found to upstream. Speaking of reporting, you must understand the responsibility you’re taking upon yourself when becoming maintainer. ALL bug reports from Debian users will come to you, and it’s your duty to act as a catalyst between the users and upstream in order to fix all issues.
Many of you, especially the older ones like me, have seen the Karate Kid series. If anything, that movie shows a relationship between a master and an apprentice (OK, you can use Star Wars as an example as well…). If you think that you ask to become a developer and your wish is granted in minutes, you forgot about patience. No, you need to ask for mentoring first, showing your accomplishments, your motivations and so on. After a while, after you’ve proven worthy, you will submit an application to become a maintainer, with the mentor vouching for you.
You’re almost there, all you have to do is perform the upload proper. If you’ve come this far, you can already pat yourself on the back. Now, the application you need is called dupload(1), and you should create a file named
dupload.conf(5) in your home directory and start modifying settings. You can, if the manual page of the file seems scary, take
/etc/dupload.conf as an example. After saving
~/dupload.conf, you can do something like this:
$ dupload yest-188.8.131.52_i386.changes
Now, it’s left as an exercise to the reader to find out what else must be done when uploading a package for the first time. Also, chapter 9 of the Debian New Maintainer’s Guide should be read and read again and then some more. That’s about it!
All articles in this series:
- I. C development on Linux – Introduction
- II. Comparison between C and other programming languages
- III. Types, operators, variables
- IV. Flow control
- V. Functions
- VI. Pointers and arrays
- VII. Structures
- VIII. Basic I/O
- IX. Coding style and recommendations
- X. Building a program
- XI. Packaging for Debian and Fedora
- XII. Getting a package in the official Debian repositories