Packaging using gbp

From LSDevLinux
Revision as of 16:50, 29 October 2015 by Mayhewn (talk | contribs) (Overview: Fix bad formatting)

Jump to: navigation, search

Overview

gbp or git-buildpackage is a utility that supports maintaining a Debian/Ubuntu package in git. It takes care of a lot of the details and ensures consistency and correctness.

gbp is only for quilt packages (ones that have a segmented version number and potentially have patches against the upstream source). For native packages (which have a single tarball instead of separate orig and debian tarballs) gbp doesn't provide anything of value and it's better just to use git directly.

A gbp-compatible repository has two main branches:

  1. upstream
  2. master

The upstream branch is used to store the content of successive upstream ('orig') tarballs, and each upstream release is tagged.

The master branch is forked from upstream and adds the debian/ directory. It has tags for each package release.

When a new upstream version is integrated, the upstream branch is merged into master.

There's usually also a pristine-tar branch that's used in conjunction with upstream to recreate exact copies of the original upstream tarballs.

Some of our packages are modifications of existing Debian or Ubuntu packages and use a fork of the upstream gbp repo. In this case, it's necessary to use a branch other than master for our versions, and we usually use a branch name sil for this. This requires passing a --git-debian-branch=branchname option to gbp to tell it which branch to use. This is noted when it's relevant in the following descriptions.

Cloning the repo

Our package repos are on git.lsdev.sil.org rather than github and have URLs of the form

ssh://git.lsdev.sil.org/srv/git/lsdev/public/debian/PACKAGE (read-write)

and

git://git.lsdev.sil.org/debian/PACKAGE (read-only)

Although they can be cloned with the regular git command, it's better to clone them with gbp because this will set up the right branches:

   gbp clone --pristine-tar ssh://git.lsdev.sil.org/srv/git/lsdev/public/debian/PACKAGE

If a branch other than master is being used for packaging, as explained above, then an additional --git-debian-branch=branchname option will need to be included in the command above.

Adding a new patch

For a quilt-format package, differences from the upstream release are stored as a series of patches in debian/patches/. gbp can import these patches into a temporary branch called a patch-queue which is never pushed to the shared (remote) repository. The developer then makes new commit(s) on this branch, and uses gbp to export the branch back to debian/patches/. The updated debian/ directory is then committed to the master branch.

The exact steps are as follows:

git checkout master
Start from a known state
gbp pq import
Turn the patches into commits on a temporary branch and switch to it. You are now on patch-queue/master
HACK, COMMIT, HACK, COMMIT, HACK, COMMIT ...
Your commits will become new patches
git pq switch
Switch away from the patch-queue branch back to the main branch
git status
Check for extraneous files and uncommitted changes
git clean -dxf
Remove extraneous files
gbp pq export
Update debian/patches/
git status
Review the added/changed patches
git add debian
Stage everything under debian/
git commit -m "Add patch(es): ..."
List the patches in the commit message
gbp dch -R -c
Update the changelog and open it in an editor for final adjustment. You can usually just save and quit.
gbp buildpackage --git-pristine-tar --git-tag -nc -S
Build a source package

If the branch being used for packaging is not master but some other branch (eg sil) then above procedure needs to be modified slightly. As well as replacing all references to master with the actual branch name, the dch and buildpackage commands will need an extra parameter:

gbp dch -R -c --debian-branch=branchname
gbp buildpackage --git-pristine-tar --git-tag -nc -S --git-debian-branch=branchname

Note that the two commands use differently-named options!

When you've built and tested the package, please remember to push your changes (including tags) to origin.

Additional notes

  • It's also possible to pull from an upstream git repository directly, rather than using tarballs. See the gbp documentation for details.
  • gbp can run pbuilder builds directly, but we're not set up for that currently.