Hello,
First, I'm not a Debian maintainer, I mostly do some package for my
personal use, to follow SVN trunk or git HEAD of some softwares.
As I use Debian, I do not want to make install things ;-).
I attach[1] a rough document about my actual uses of git for debian
packaging and post it here for comments.
There are some items about which I would like to discuss, like:
- automatic handling of debia/changelog
- multi-distributions/version packaging (and avoiding conflicts)
- automatic build of packages
- management of orig.tar.gz
I already read some maling-list archives, mostly the Patch mgmt
workflow proposal plus the links givent in the thread, but the
conversations are way to high for me.
I read the Debian wiki[2] plus its links, I like Russ Allbery page[3],
it's a real life example[4].
Regards.
Footnotes:
[1] I need to setup some web access to my git repositories ;-)
[2] http://wiki.debian.org/PackagingWithGit/
[3] http://www.eyrie.org/~eagle/notes/debian/git.html
[4] Thanks for the trick to split a upstream/debian combined source
http://www.eyrie.org/~eagle/notes/debian/git.html#combine
--
Daniel Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1
#+TITLE: Manage Debian packaging with git
#+AUTHOR: Daniel Dehennin
#+LANGUAGE: en_GB
* Introduction
This documentation is based on my personal packaging of the
enlightenment display manager: elsa.
It's code can be found in the enlightenment [[http://svn.enlightenment.org/svn/e/trunk/PROTO/elsa][SVN repository]].
* git-buildpackage workflow
My current usage is [[https://honk.sigxcpu.org/piki/projects/git-buildpackage/][git-buildpackage]] oriented:
- One branch is upstream
- One branch is patches to upstream sources
- One branch is packaging
Upstream is mostly VCS based, I do not use the [[http://kitenet.net/~joey/code/pristine-tar][pristine-tar]] mechanism.
My first use was to package SVN/git snapshot of some softwares like
cfengine3, gnus and elsa.
For convention I always use a dedicated mirror of upstream branch, in
which I only pull from upstream.
Another convention is to always prepend my trigraph (=dad/=) to my
branches.
The basic setup is the following:
- Upstream branch is under =upstream/= and reflect the VCS used by
upstream: =upstream/svn/trunk= or =upstream/git/master=
- Packaging: =dad/debian/snapshot=
- Patches to upstream: =patch-queue/dad/debian/snapshot=
** git-buildpackage configuration
I use one global full git-buildpackage configuration, stored
in =~/.gbp.conf= and one minimal configuration per packaging.
The following is my default, I use pbuilder to keep a clean
workstation and track dependency problems.
#+begin_src conf
# Configuration file for git-buildpackage and friends
[DEFAULT]
# Where I track upstream
upstream-branch = upstream
# Branch I use to build package
debian-branch = debian/snapshot
# the default tag formats used:
upstream-tag = upstream/%(version)s
debian-tag = debian/%(version)s
# Use a clean environment to build
# Need some setup with sudo cowbuilder --create
builder = /usr/bin/git-pbuilder
# Use color when on a terminal, alternatives: on/true, off/false or auto
color = auto
[git-buildpackage]
# Look for a tag matching the upstream version when creating a tarball
upstream-tree = tag
# Sign tags by default:
sign-tags = True
# Sign after the build, required because of cowbuilder
postbuild = debsign ${GBP_CHANGES_FILE}
# Let the working tree clean
export-dir=../build-area
# Transparently handle submodules
# submodules = True
[git-dch]
# Use my git identity
git-autor = True
# Merge the commits by maintainer
multimaintmerge = True
# Do not use merge log
git-log = --no-merges
# Parse meta tags like Closes: from commit messages
meta = True
# Add seven digits of the commits sha1 to the commit message
id-length=7
# Regex for matching bugs to close
meta-closes = Closes|LP|BZ|Fixes|fixes
# Use the full commit message instead of the first line only
full = True
# Ignore these in commit messages
ignore-regex = (git-svn-id|(Signed-off|Acked)-by):
#+end_src
** Setup a new package
*** Base is upstream repository
As I do not use pristine-tar, everything is based on the upstream
version control repository.
If upstream do not use git, you must look for a plugin to make the mapping.
Actually I tested following SVN and bzr repository, I may write some
separate documentations about this but for the moment I just show how
to start from SVN and git.
SVN upstream
#+begin_src sh
dad@home:~/src/$ git svn clone --prefix=upstream/svn/trunk http://svn.enlightenment.org/svn/e/trunk/PROTO/elsa cd elsa
dad@home:~/src/elsa$ git branch upstream/svn/trunk upstream/svn/trunk
#+end_src
Git upstream
#+begin_src sh
dad@home:~/src git clone http://git.gnus.org/gnus.git cd gnus
dad@home:~/src/gnus$ cd gnus git branch
