You would like to contribute to dpkg? Perfect, here a few simple steps to get you started.

Contents

  1. Pre-requisites
  2. Initial setup
  3. Submitting a patch
  4. Running the functional test-suite
  5. Find something to do
    1. Use the Git version of dpkg and report problems
    2. Triage bugs
    3. Contribute a functional test

Pre-requisites

You should know either Perl or C if you want to contribute code. If you want to contribute only to documentation, you should learn POD (Perl's Plain Old Documentation format for the manual pages and be familiar with PO files used for translating the documentation.

Ideally you have some packaging experience and you know what the various dpkg tools do. You can learn on the fly but it will require some supplementary efforts to train yourself when you are not familiar with something.

Initial setup

Submitting a patch

If you are new to git, here is a short tutorial for this specific task. Don't stop at this, you should really learn Git. Start with this tutorial. You should learn how to manage "topic branches", how to rebase them, etc.

Running the functional test-suite

dpkg has some non-regression & unit tests integrated in its main repository (see t/, lib/dpkg/t/, src/t/, utils/t/, scripts/t/), and also functional tests covering the run-time behavior of dpkg itself (tests/).

By default the test suite will run without privileges using dpkg's chrootless support and will test the binaries build in the source tree, you can also test the installed binaries as non-root or as root, with one of the following invocations:

Refer to the tests/README file for any prerequisites. If you want to execute a single test, you can do make -C tests <name>-test where <name> is the name of the directory containing the test.

If the test-suite fails, you'll see an error message from make like this: 

make: *** [test-case] Error 1
make: Leaving directory `...'

Note that in that case, you should probably run make -C tests test-clean to get rid of the cruft that was left installed on the system.

Find something to do

Use the Git version of dpkg and report problems

You can add the following repository to your sources.list. It always contains the latest build (for amd64/i386) of dpkg's main branch (built in a "sid" environment of course) 

deb https://jenkins.grml.org/debian dpkg main

You will want to install the corresponding OpenPGP key to avoid APT's error due to unauthenticated packages: 

$ wget -O - https://jenkins.grml.org/debian/C525F56752D4A654.asc | sudo apt-key add -

You can report bugs with a simple mail to debian-dpkg@lists.debian.org. Often a notice on IRC (#debian-dpkg) is also enough but if you don't get a response there, please send an email.

Triage bugs

You can help dealing with the flow of incoming bugs:

Of course, you're welcome to do the same on old bugs too! In fact, that's where the help would be most useful.

Contribute a functional test

Adding a new non-regression functional test to tests/ is really easy. Let's assume we want to add a new test that we call "foo". We'll create a new directory tests/t-foo and put a simple Makefile inside: 

TESTS_DEB := pkg-foo

include ../Test.mk

test-case:
        # All commands here must succeed for the test to pass
        $(DPKG_INSTALL) pkg-foo.deb
        $(call pkg_is_installed,pkg-foo)
        $(DPKG_PURGE) pkg-foo

test-clean:
        -$(DPKG_PURGE) pkg-foo

The variable TESTS_DEB defines a list of deb files to build. In this case, pkg-foo.deb will be built from the the tests/t-foo/pkg-foo/ directory. It's up to you to add this directory with the proper files so that dpkg-deb -b pkg-foo creates the needed package.

The included Makefile snippet (../Test.mk) contains the required rules to build the deb files before running the test and to clean them. It also contains some macros (that you can use with $(call)) to ease writing some common tests.

The test-case target is the one that you must customize to execute the actual test. If you have many tests, you can use multiple targets and add them as dependencies of test-case: 

test-case: test-foo-1 test-foo-2
test-foo-1:
        ...
test-foo-2:
        ...

The test-clean target is here to cleanup everything after the test, in particular if the test failed. Usually individual tests should clean up after themselves when they succeed so that further tests are not influenced by lingering files from tests previously run.

Once you're satisfied with your test-case, you should add it to the list of tests in the tests/Makefile (variable TESTS_PASS).