Joseph Herlant
version 1.0.0, 2014-03-13 : Initial version

1. General topcis

Where to begin: an ontroduction of packaging process in Debian: http://mentors.debian.net/intro-maintainers

Build environments are restricted environments. To have and overview of that, see: https://wiki.debian.org/buildd

Look at what’s on your computer that needs help, install the devscripts and how-can-i-help packages. From the first, use the rc-alert and wnpp-alert scripts. From the later, use the how-can-i-help -o or (if you want to help on packages not installed on your computer yet) how-can-i-help -a.

To have a complete overview of how to maintain a package, refer to the official maintainer guide: http://www.debian.org/doc/manuals/maint-guide This document is a gold mine!

2. Tools for testing your packages

Pbuilder: http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html

https://wiki.ubuntu.com/PbuilderHowto

https://wiki.debian.org/PbuilderTricks

Cowbuilder: https://wiki.debian.org/cowbuilder

Sbuild: https://wiki.debian.org/sbuild

Qemubuilder: https://wiki.debian.org/qemubuilder

3. General tips

Don’t do NMU (Non Maintainer Uploads) on packages with maintainers. NMU is more considered as something quite rude than a grood practice. If you have corrected a bug, provide the patch. An upload will be made by the maintainer when he founds some time and enough bugs to make a release. So when you provide a patch, go and work on others.

Take your time ! Test your pach on several environment, play with the patched package a few days to check for any side effect. Some bugs can stay open for years. If you set yourself as the owner of the bug, there’s no need to hurry!

Begin small. If you want to maintain packages, begin with correcting some bugs first (that’s my own advise). 20 or more on different packages could be a good start in my mind. That helps understanding how packages are made and how Debian developement works. Then cleanup and adopt an orphaned or a package in RFA state or if you want to be part of a packageing team, see the RFH bugs.

4. Packaging tips

4.1. debian/control file

When you have no architecture-specific files, use "Architecture: all" instead of "Architecture: any". This way the package won’t be rebuilt for each platforms, saving time and resources. It will also produce one binary package for all the platforms instead of one for each architecture. Example: for packaged based on python, ruby, javascript or other interpreted languages.

Description synopsis should be 80 chars max (Policy 3.4.1) and not end by a period (Developper reference 6.2.2).

When changing the description, it’s always better to validate it by sending a mail to debian-l10n-english@lists.debian.org

Priority should generally be set to "optional".

Use the wrap-and-sort -s command from devscripts to have a clean and sorted debian/control file.other files are also cleaned during this process. Beware: it removes the commented lines!

4.2. debian/patches

When doing a patch, don’t forget to add DEP-3 headers using quilt header -e.

When using a debian/source/format containing 3.0 quilt, you don’t need:

  • the --with quilt after the dh $@ in the debian/rules file

  • to set quilt as a build-dep in debian/control file.

  • to use the dh_quilt_patch / dh_quilt_unpatch (it’s done automatically)