Packaging and Git Guide


git - Debian Perl Group Packaging and Git Guide


This guide describes the procedures that the Debian Perl Group contributors use to maintain packages in the Git repositories on

It covers the following tasks:

* Creating a new Debian package from a Perl module.

* Updating the repository for a package.

* Building a package and preparing it for upload.

* Uploading a package to the Debian archive.

* Upgrading a package to a new upstream release.

* Getting the source for all packages with mr(1).

The guide is a work in progress. Different people tend to do things in different ways. If your way diverges, you may want to document it here so that others can benefit. Please send any comments or ideas to <>.

For a more general guide to Git, see the Git User’s Manual at

The Tools

First, you need to install pkg-perl-tools. It contains a collection of scripts useful for the day to day work.

Each group package has its own Git repository. If you are working with multiple packages, then you will probably want to use mr(1) to manage the multiple Git repos involved. For this workflow, you’ll need the following packages installed:

* git (>= 1:

The version in squeeze has buggy command_bidi_pipe method

* myrepos or mr (>= 0.50)

for the post_update feature

* Helper perl scripts in the meta.git repository

Check out meta.git repository with

$ cd $HOME/src
$ git clone ssh:// pkg-perl

At this point it is a good time to configure dpt(1). Decide where you want to store the cloned repositories, and tell dpt about it. For example:

mkdir $HOME/src/pkg-perl/packages
echo "DPT_PACKAGES=$HOME/src/pkg-perl/packages" >> $HOME/.config/dpt.conf

Note: the meta.git repository should be cloned in such a way, that it contains the packages directory above.

Packaging walkthrough

starting a new package

a) the “all-in-one” approach

When called with --pkg-perl options, dh-make-perl populates a Git repository with master, upstream and pristine-tarbranches, and sets up an origin remote pointing to Alioth.

$ dh-make-perl [option] --pkg-perl --cpan Foo

b) alternative: adding Git stuff manually

gbp import-dsc imports the source of a package into the Git repository. It operates on the .dsc file and the associated source files.

Example of starting a new package from scratch:

$ dh-make-perl [option...] --pkg-perl --cpan Foo
$ mkdir libfoo-perl
$ cd libfoo-perl
$ git init
$ gbp import-dsc --pristine-tar ../libfoo-perl_1.23-1.dsc

If the package is already in Debian and you want to add a bit of history to the repository, repeat the last command for all .dsc files you have, in incremental version order. Alternatively you could use gbp import-dscs.

Note that dh-make-perl(1) has many options to make your life easier.

Attention: gbp-import-dsc(1) adds a debian/$version tag. This one should not be pushed for new packages (but deleted, and later created after the first upload). - Since version 0.6.0, gbp-import-dsc(1) has a switch –skip-debian-tagto avoid creating the debian/$version tag.

c) more alternatives

An alternative for a new package, as described in (“Importing a package” -> “If you’re instead starting from scratch ...”), is to create a new empty repository and then use dpt-import-orig(1), gbp-import-orig(1) and dh-make-perl(1).

If your package does not have a .dsc file you can use (running from the new empty repository):

$ gbp import-orig --pristine-tar ../libfoo-perl_1.23.orig.tar.gz

working with existing packages

cloning a single package repository

$ dpt checkout libfoo-perl

This will go to $DPT_PACKAGES/libfoo-perl and invoke gbp-pull(1). If the directory does not exist, gbp-clone(1) is used to create the initial clone.

You could do it manually, of course:

$ cd $HOME/src/pkg-perl/packages
$ gbp clone --all --pristine-tar ssh://

tracking all repositories on Alioth with mr(1)

Add the following to your ~/.mrconfig, creating it if needed:

chain = true
checkout = git clone ssh:// pkg-perl


* The destination path has to be under the location of the .mrconfig file; i.e. [/tmp/foobar] in ~/.mrconfig is not supported.

* The last part of the path has to be the same as the target of the clone command (in this example: pkg-perl).

You then need to explicitly trust ~/src/pkg-perl/.mrconfig, by adding it to ~/.mrtrust, otherwise the chain feature will be disabled for security reasons.

Now run mr up to clone the meta repository, which contains another .mrconfig with some features and some helper scripts.

A second invocation of mr up clones all the repositories listed in meta‘s .mrconfig, i.e. all pkg-perl git repositories in /git/pkg-perl/packages on

For the adventurous:

mr --trust-all bootstrap

does mostly the same, except that the authenticity and integrity of the initial .mrconfig are not checked in any way.

repository layout

Upstream sources are kept (in plain, uncompressed form) in the upstreambranch. The data needed to regenerate original source tarballs from the upstream branch are kept with the help of the pristine-tar(1) tool in the pristine-tar branch. Upstream sources are merged with Debian-specific changes in the master branch, which is the usual place to work in.

From this point on, work on the package normally. Some prefer to update debian/changelog with each commit, others leave this to the gbp-dch(1) tool at package release time. In case you use gbp-dch(1) for the changelog entries, don’t forget to use it when you stop working on the package.

pushing to

There are several ways to do this. Please read this section. The pkg-perlrepositories use some infrastructure that is set-up by the below methods. Non-pkg-perl methods such as gbp-create-remote-repo will not set up this infrastructure.

a) the easy way

The first time:

$ dpt alioth-repo

This connects via SSH to alioth, runs setup-repository there with the right arguments, then pushes the local repository over there.

From then on, just use dpt push as usual or use mr(1) for committing, which also pushes the changes to the original repository on Alioth, mimicking the subversion commit behaviour at the expense of the ability to make amends, squashes and splits of commits (you still have to push any non-active branches or tags via git push). – Note that the mr(1)’s feature to push-on-commit is turned off if you use our .mrconfig from the metarepository as described above.

b) alternative: the long story

Before pushing to for the first time, an empty repository needs to be created there. To do this, use the setup-repository script available in the /git/pkg-perl directory. Run it similarly to:

$ ssh
$ cd /git/pkg-perl
$ ./setup-repository libfoo-perl 'Packaging of FOO in Debian'

This creates an empty, bare, shared Git repository and setup some hooks.

Now, on your local machine add the Alioth repository as a remote:

$ git remote add origin ssh://

Then push to it:

$ git push --all --set-upstream
$ git push --tags

The --set-upstream option helps future use of git pull.

building the package

Use your favourite way of building the Debian package. If the source tarball is not in ../, check it out from the pristine-tar info (not needed if you use git-buildpackage(1) with the settings mentioned in Tips & tricks|/Tips & tricks below):

$ pristine-orig

Or, if you want a version which is not on the top of debian/changelog, or you simply like to type a lot:

$ pristine-tar checkout ../libfoo-bar-perl_1.23_orig.tar.gz

This requires that you have the pristine-tar branch current (e.g. via git fetchor gbp-pull(1)).

After uploading, tag the release. The easiest way is to use debcommit(1)

$ debcommit -a -r

Push the result afterwards:

$ dpt push


$ git push origin master upstream pristine-tar
$ git push --tags

uploading a package

Only official developers have permission to upload packages to the archive (see the Maintainers’ Guide in

In case you aren’t an official developer you just have to change the release dch -r and push the changes. Thus, the package will be listed in the Ready For Upload section in PET and someone else will perform the upload on your behalf.

upgrading to a new upstream release

First make sure that the local repository is up to date, for example using gbp-pull(1).

If the Debian package has a debian/watch file you can use the uscan(1) tool to check for the latest upstream release and download it.

importing the new upstream sources

using gbp import-orig –uscan

gbp-import-orig(1), when used with its --uscan option, acts as a frontend for uscan:

$ gbp import-orig --uscan --pristine-tar

Basically, this command downloads the latest tarball and imports it into the Git repository: the new sources are imported into the upstream branch, tarball data is put into the pristine-tarbranch, the upstream release is tagged and finally that tag is merged into the master branch.

using plain uscan
$ uscan

This downloads the latest tarball in ../ and symlinks it to the proper .orig.tar.gz (you can use the --rename options of uscan to directly rename the tarball without symlinking). If the watch file is not present you have to download the tarball manually.

Then import the new upstream release in the git repository:

$ git fetch origin upstream:upstream pristine-tar:pristine-tar
$ gbp import-orig --pristine-tar ../libfoo-bar-perl_2.00_orig.tar.gz

last steps

Create a new debian/changelog stanza about the new upstream release:

$ dch -v2.00 'New upstream release'

Can be automated by the following configuration in ~/.gbp.conf:

# run hook after the import:
postimport = gbp dch -N%(version)s -S -a --debian-branch=$GBP_BRANCH

Commit the changes so far:

$ debcommit -a -m'new upstream release 2.00'

Don’t forget to share your work when ready:

$ dpt push


quilt(1) does a fine job managing patches, especially if using the 3.0 (quilt) source format. See for a guide. gbp-pq(1) can be used for treating the patches as a series of commits. See


From time to time, there is a need to work in a branch for a stable update or a security fix. Things are simple:

First create a branch from the tag that represents the version currently in the archive:

$ git checkout -b squeeze debian/2.40-5

If the squeeze branch already exists, check it out and merge the version currently in the archive:

$ git checkout squeeze
$ git merge debian/2.40-5

From this point on, work normally in the squeeze branch, build, tag and push.

Mass changes

For changes across many repos. - Just do them and

$ mr commit

from within the top directory of the repositories.

Our global ~/.mrconfig redefines mr commit to not push to the repositories. Therefore, after commiting:

* Disable the KGB notifications:

$ ssh touch /home/groups/pkg-perl/KGB-notifications-disabled

* Push to the Git repositories: mr push

* Re-enable the KGB notifications:

$ ssh rm /home/groups/pkg-perl/KGB-notifications-disabled

This has to be done by hand until we have a way to disable them dynamically on mass commits.

Commit policy

single change per commit

This is true for any VCS, but it won’t hurt saying it again: please include only one change in each commit. git-gui(1)’s and git add -p‘s ability to stage single lines (or hunks) is a huge help if you have done several unrelated changes in the sources.

changelog maintenance

Some prefer to update debian/changelog with each commit, while others prefer to do that only at release time by using gbp-dch(1). The current group policy states that whenever you stop working on a package, the changelog should be updated and pushed. That is, either include the changelog entry with each commit, or finish your work by updating the changelog, e.g. via gbp-dch(1).

Removing packages

When there is need to remove a package from the group you can either remove it completely (if added without never being released) or move it to attic. It can be done by using remove-repository on moszumanska.

Renaming packages

When there is need to rename a package from the group the git reposiory should be renamed as well. This can be done by using rename-repository on moszumanska. The script will rename the repository, update it’s description and update ~/.mrconfig.

rename-repository old-package new-package

Tips & tricks

How to have git-buildpackage not ask for a password so often ?

One of the annoying things about git-buildpackage is that when you check out a package using the git+ssh protocol, it asks your password pretty often when building, about 25 times. This tends to get annoying by the second time you have to type in your password. To avoid this, upload your public SSH key in the alioth account area (

Note that even if ssh-copy-id(1) seems to work, this is only temporary since the authorized_keys file is re-generated from the Alioth account info every now and then.

To avoid typing even the public key passphrase you may want to run SSH agent (see ssh-agent(1), included in the openssh-client package).

What if your username is different from your local username?

The URLs used above for git commands assume that your username on is the same as your local username. If this is not the case, you can put user@ in front of in all of the URLs, but this is ugly (*can it cause problems with ``git-buildpackage`` ? *).

You can solve this problem with your local ssh configuration, however. Edit ~/.ssh/config (creating it if you don’t already have it) and add a stanza for like:

    User <user>

replacing <user> with your username on This tells sshto use that username by default when connecting to unless another is specified, and lets you use git with the default URLs.

how to save typing when using pristine-tar ?

git-buildpackage(1) has a configuration file which can save some typing on each command. The pristine-tar option is particularly handy.

An example of configuration file:

pristine-tar = True
sign-tags = True

This may be stored for example in ~/.gbp.conf (per user configuration), in debian/gbp.conf (per branch configuration) or in .git/gbp.conf(per repository configuration).

If using the 3.0 (quilt) source format may also be handy to add the .pc directory to the .gitignore file. To do this globally, you may use the following:

git config --global --add core.excludesfile ~/.gitignore
echo '/.pc/' >> ~/.gitignore

(If you have a Git repository in your home, you probably want to use something else than ~/.gitignore for the global excludes file).

More goodies from pkg-perl-tools

Take a look at dpt(1) and the other scripts in the pkg-perl-toolspackage.

What’s in meta.git

This contains the following useful scripts:

* compare-hashes

Used in <.mrconfig> to filtersout unnecessary pulls. Uses a couple of non-core Perl modules and complains if those aren’t present.

* pkg-perl-post-receive

Used by the post-receive hooks of the git repos on alioth; runs KGB (IRC notifications), updates the PET database, and sends mails to the commit list.

* remove-repository

Used on alioth. Deletes a repository with less typing. Should be run from a shell on moszumanska. See Removing packages for more detail.

* rename-repository

Used on alioth. Renames a repository with less typing. Should be run from a shell on moszumanska. See Renaming packages for more detail.

* setup-repository

Sets up a remote repository. Should be run from a shell on moszumanska. This is normally done for you by dpt alioth-repo. See here|b) alternative: the long story for more detail.

* split-json-info

Used in .mrconfig.


Git is detached. This is very good, when you happen to work mainly offline or on the road. The problem is not to forget to publish your work at some point in time :)

Various shell hooks that change the prompt may be of help.


* Damyan Ivanov

* gregor herrmann


Copyright (c) 2010-2013 by the individual authors and contributors noted above. All rights reserved. This document is free software; you may redistribute it and/or modify it under the same terms as Perl itself

Perl is distributed under your choice of the GNU General Public License version 1 or later or the Artistic License. On Debian systems, the complete text of the GNU General Public License version 1 can be found in `/usr/share/common-licenses/GPL-1’ and the Artistic License in `/usr/share/common-licenses/Artistic’.