Christoph's Debian package sponsoring guidelines

Tags: 

I would like to help any developers to get their software into Debian. So I'm offer sponsorship for your packages. I created this page to give you a bit of information about how I think sponsoring can be easy for both of us.

 Debian GNU/Linux only allows approved developers to upload new software packages into the distribution. However the procedure of becoming a developer is very sophisticated and takes a lot of time. Some people argue that this is necessary to keep a high level of quality in Debian. However there are people who like to maintain Debian packages without becoming a Debian developer. Opposed to what other developers believe I am perfectly happy with this. The process of uploading packages on behalf of a non-approved developer is called sponsoring. It has nothing to do with money though. Sponsoring means that you create a Debian package and have it checked and uploaded by a Debian developer. The person actually maintaining the package is called a sponsoree. The developer who is uploading your package is called the sponsor. Still it is the sponsoree's name that is on the package. So the honor is yours.

By the way... should you be interested in becoming an approved developer yourself you will need an advocate. That is a person who tells the people who will be processing your application that you are welcome to Debian and that your development skills are good. If we have worked on packages for a while I will gladly advocate you.

Let me find you

I am following the debian-mentors@lists.debian.org mailing list. So your best chance is to tell us about your package there. I will read it. Please do not ask me to sponsor a package. If I do not offer sponsorship there is often a reason like lack of time.

Read the basic documentation

I lack the time of explaining the basics of package building. Honestly I do not mean to sound arrogant. But there is good documentation already. The least I expect is that you know the New maintainer's guide. It is really helpful if you know the Debian Policy Manual although it's a huge document and has more of a bible. It probably makes more sense reading parts of it as you go. At some point during our relationship I will probably bombard you with link to the policy manual.

Get your package online

You may already put up your package on the internet. A service dedicated to keeping sponsorees' packages is http://mentors.debian.net People reading your RFS (Request for Sponsorship) expect that your package can be downloaded and looked at.

I prefer simple packages

Not only because I am not yet a guru maintainer. But also because checking complex packages takes time and energy. I maintain a couple of packages myself - some of them not being very simple. You have the best chance of having me sponsor your package if I can instantly test it - like a standalone application. I am less a fan of library packages or developer packages that are hard to check myself.

I prefer debhelper

Although I know a little bit about CDBS and the classic art of package building I prefer the help of the debhelper tools like dh_install in the debian/rules makefile.

I prefer fixes

There are already a lot of packages in Debian that are broken or badly maintained. I will prefer your package if it fixes a filed bug or is a new version to a package already in Debian. Orphaned packages are also a good choice.

Make contact with the upstream

The upstream is the developer who wrote the actual software that you made a Debian package of. It is important that the package is still actively maintained. If anyone finds a bug that is coming from the upstream then we need a way to have it fixed. Your job is just to build good Debian packages - not fix upstream bugs. Make sure the upstream is friendly and helpful. Fear not, most upstreams are flattered to hear their software makes it into Debian.

I prefer long-term sponsorship

There is nothing worse than a package that you are interested in for a week and then silently drop it. Debian deserves to contain well-maintained packages.

My favorite conversation medium is IRC or Jabber

Since sponsoring packages often means improving the package here and there it will be hard to get your package uploaded in time if we can't find a way to communicate. Although I read my emails a couple of times per day it is also often nice to communicate directly. It helps if you use IRC or Jabber.

Things you can check already

To speed up the process I suggest you check these issues before sending me your work:

  • the package should be lintian clean (or you have a reason why it's not)
  • same for linda
  • try building it in a pbuilder environment (see HowToUsePbuilder) to see if you got the dependencies right
  • make sure your package is not a native package (after building the package you should get a file ending in .diff.gz)
  • if your package is new to Debian (no previous version) I suggest you already
  • file an ITP (Intent to Package) in the BTS
  • make sure the copyright file is decent (see the policy)

What I will do

I have created a checklist for myself. This is what I do when I sponsor packages:

  1. get your .diff.gz file (containing your actual work)

  2. get the original tarball (please make it easy for me to find it)

  3. unpack the original tarball (tar xvzf *orig.tar.gz

  4. apply your patch file cd package; zcat ../*diff.gz | patch -p1

  5. make the rules file executable chmod +x debian/rules

  6. build your package (I use pbuilder for that)

  7. check your package for common mistakes (lintian -i *.changes / linda -i *.changes

  8. install your package and test it (dpkg -i

Finally if everything is okay I will sign the package and upload it to Debian.

If you have packaged a new version of a certain software I will unpack and patch both the old version and the new version and use kdiff3 on both directories. That allows me to see your changes very easily.