Differences between revisions 3 and 4
Revision 3 as of 2011-07-19 15:55:56
Size: 3573
Editor: AndrewLee
Comment: Put the document from Jonas' mail to his CDBS+git-buildpackage page.
Revision 4 as of 2012-07-25 15:53:33
Size: 3594
Editor: ThomasKoch
Comment:
Deletions are marked like this. Additions are marked like this.
Line 102: Line 102:

----
CategoryGit

Package maintainance using CDBS and git-buildpackage

Building the package

No special handling is required for normal package builds.

Upgrading to new upstream source

Official releases are tagged and signed and binary diffs of tarballs are stored using pristine-tar. This is documented below /usr/share/doc/git-buildpackage/manual-html/.

A custom build target shows current upstream and packaging versions:

debian/rules print-version

Current upstream tarball can be prepared using this other build target:

debian/rules get-orig-source

To switch to newer upstream source, first add a dummy changelog entry and comment out DEB_UPSTREAM_TARBALL_MD5 before getting the source:

dch -v ${new_upstream_version}-1 "Dummy changelog entry"
sed -i -e 's/^\(DEB_UPSTREAM_TARBALL_MD5\b\)/#\1/' debian/rules
debian/rules get-orig-source

Store new md5sum to help ensure identical source is received later.

Other upgrade methods using the watch file may work too but is currently discouraged, especially when repackaging to strip non-DFSG files is needed.

Maintaining packaging build routines

This source package wraps debhelper commands and other tedious parts of the build routines using the CDBS framework. Please refer to the actual makefile snippets included from debian/rules for details on their purpose and ways to override defaults.

Setting DEB_MAINTAINER_MODE=1 enables additional build routines helpful during development of the package, but unfit for normal builds. This typically includes the CDBS feature of auto-updating debian/control with CDBS-related build-dependencies, which is forbidden by Debian Policy as build environment must not change during automated builds.

Use git for your package at collab-maint area of Alioth

Create new git locally from pristine tarball:

    mkdir mypkg
    cd mypkg
    git init
    cd ..
    mkdir tarballs
    cd tarballs
    wget http://example.org/source/my_pkg-1.2r3.tgz
    mv my_pkg.tgz mypkg_1.2.3.orig.tar.gz
    cd ../mypkg
    git-import-orig --pristine-tar --sign-tags ../tarballs/mypkg_1.2.3.orig.tar.gz

Create debian packaging

    mkdir debian
    nano debian/rules
    nano debian/control
    nano debian/gbp.conf
    ...
    git add debian
    git commit

Publish git at collab-maint area of Alioth

    git remote add origin git.debian.org:/git/collab-maint/mypkg
    git config branch.master.remote origin
    git config branch.master.merge refs/heads/master
    ssh git.debian.org "cd /git/collab-maint && ./setup-repository mypkg 'mypkg Debian packaging'"
    git push --all; git push --tags

If you already have some Debian packaging then it is even easier

Bootstrap local git

    git-import-dsc --pristine-tar --sign-tags mypkg_1.2.3.dsc

Or more elegantly you can bootstrap with as much history from past packaging as is possible:

Bootstrap local git

    iceweasel http://packages.qa.debian.org/m/mypkg.html
    (copy URLs from icons at right of "versions" in left side)
    dget -d http://ftp.debian.org/debian/pool/main/m/mypkg/mypkg_1.2.2-6.dsc
    ...
    iceweasel http://snapshot.debian.net/package/mypkg
    ...
    git-import-dscs --pristine-tar --sign-tags mypkg*

You might still want to apply my cdbs-skel files. Use same commands and follow the git instructions to resolve any conflicts that might occur (if e.g. the packaging already contained a README.source).


CategoryGit