Co-maintaining a Debian package with Git and git-buildpackage
Although I'm still not entirely comfortable with Git for revision control I partly use it to maintain my Debian packages. Mainly because hg-buildpackage has been abandoned and git-buildpackage is actively maintained. This article deals with co-maintaining a Debian package with Git and git-buildpackage.
Install Git
On the development workstation (where you build the packages - running Sid):
- aptitude install git-core git-buildpackage pristine-tar
Make sure you set your name and email address in your ~/.gitconfig file via:
- git config --global user.name '<name>'
- git config --global user.email '<email>'
On the publicly available web server (where you publish your repository - Lenny or newer):
- aptitude install git-core git-daemon-run gitweb
Move an existing Debian source package under Git control (only if there is not yet a repository containing the package!)
Either: Import the source package into a fresh Git repository
- git-import-dsc --pristine-tar /path/to/package*.dsc
This creates a package/ directory containing a Git repository with two branches. The default branch "master" contains the debianized source package (like what you would get after running 'dpkg-source -x *dsc'). The other "upstream" branch contains what was in the orig.tar.gz upstream tarball. You can see the branches with 'git branch -a'. Each upstream version gets a tag like "upstream/1.3.4" and each Debian package gets a tag like "debian/1.3.4-3". You can see the tags with "git tag".
If you want to import further source package versions/revisions you can either run git-import-dsc in the order of their revision numbers or use 'git-import-dscs'.
Building the package can then be done through:
- git-buildpackage --git-pristine-tar
The 'pristine-tar' is important if a previous revision of this upstream version has already been uploaded to Debian. If you don't use pristine tars then the created orig.tar.gz may be slightly different (not in content - but as an archive) from what's already in Debian and the ftp-master will refuse your upload. If you forgot the '--pristine-tar' option then at least make sure you have the orig.tar.gz in ../ that is also in Debian.
Or: Import just the orig.tar.gz into a fresh Git repository and start debianizing
- mkdir package-name
- cd package-name
- git init
- git-import-orig /path/to/orig.tar.gz
- ...work on Debian package...
- git add debian... (or "git add ." to add everything that changed)
- git commit
- git-buildpackage
- ...upload to Debian... (dput/dupload)
- git-buildpackage --git-tag
Or: package a new upstream revision
- git-import-orig /path/to/new.orig.tar.gz
Or: pull the existing repository from your co-maintainer
- git clone URL (for example: git clone git://git.workaround.org/cream.git)
What your co-maintainer did is in origin/upstream (the orig.tar.gz's content) and origin/master (the debianized directory). Incidentally Git merged the origin/master into your own 'master' branch that you are now on. To make sure you are following the co-maintainers upstream branch, too, you'll have to run:
- git checkout -b upstream --track origin/upstream
The '--track' option altered the .git/config file and added a [branch "upstream"] section telling Git where you fetched it from. That means you can later just say "git pull" and you will get both the 'master' and the 'upstream' repository merged into your repository automatically.
Now you will have these branches:
- upstream (a copy of the origin/upstream - must not change)
- master (where you do the Debian package work in just like you had no repository underneath)
- origin/upstream (where you co-maintainer unpackaged the orig.tar.gz using git-import-orig)
- origin/master (the debianization that your co-maintainer did so far)
- pristine-tar (optional - information on how to build the binary-identical orig.tar.gz that is in Debian)
Work on the Debian package
- ...work...work...work...
- git add (what you added/changed)
- git commit
- git-buildpackage
If you like the package:
- ...upload to Debian... (dput/dupload)
- git-buildpackage --git-tag
And then...
Publish your own works to your public repository so that your co-maintainer can fetch what you did
The most efficient protocol to transport Git repositories and their changes is the git:// protocol. (You could also dump your repository into a web server's htdocs directory and let others fetch it with HTTP.)
Using git.debian.org
The Debian project is offering Git hosting at git.debian.org. You can request a new repository there through a process defined in the Debian wiki.
Using Github
Github is a nifty web service that allows hosting of Git repository. While it's debatable that Git is actually decentralized and a central repository doesn't make sense it's still nice to have a place to pull and push changes. (Of course this applies to git.debian.org as well.) Repositories up to 100 MB that are public are free (beer). They also offer paid plans.
Setting up git-daemon
git-daemon is a software to serve repositories through the git:// protocol. It looks for repositories in /var/cache/git on your public (web-) server. Put up your Git repository as a "bare" repository there. ("Bare" Git repositories just consists of what's usually in the project's .git directory but the directory is called project.git)
-
git clone --bare --mirror . ssh://myuser@myserver/var/cache/git/myproject.git
This will create a copy of your repository on the 'myserver'. "--mirror" makes it push all the branches (so you don't miss to push the "upstream" branch) and tags (without upstream/* and debian/* tags git-buildpackage would be very unhappy).
Log into 'myserver', go into /var/cache/git/myproject.git and touch the file "git-daemon-export-ok" there. It tells git-daemon that this repository is allowed to be displayed publicly. (I personally prefer to change /etc/sv/git-daemon/run and add the "--export-all" option there. Because if I clone my repository into /var/cache/git I know what I'm doing and don't accidentally put up something private there.)
To simplify pushing I recommend:
- git config remote.origin.url ssh://myuser@myserver/var/cache/git/myproject.git
- git config remote.origin.mirror true
Then you can just:
- git push
...in the future and get all your commited changes online to the public server.
Now tell your co-maintainers about it so they can "git pull git://myserver/myproject.git" from your server. Make sure you always "git pull" before you start working on the package.
Setting up gitweb (optional)
If you want to show what repositories you are offering you can run 'gitweb' on your web server. Just "aptitude install gitweb" on the server and follow the instructions in /usr/share/doc/gitweb/README*
See also
- Tags:
Recent comments
8 hours 17 min ago
16 hours 5 min ago
16 hours 26 min ago
1 day 10 hours ago
1 day 11 hours ago
2 days 17 hours ago
3 days 1 hour ago
3 days 18 hours ago
3 days 23 hours ago
4 days 1 hour ago