-
Recent Posts
-
Archives
- September 2025
- December 2024
- August 2024
- September 2023
- July 2022
- October 2021
- August 2021
- April 2021
- October 2020
- May 2020
- December 2019
- August 2019
- May 2019
- August 2018
- June 2018
- March 2018
- December 2017
- October 2016
- April 2016
- February 2016
- December 2015
- November 2015
- June 2015
- April 2015
- February 2015
- January 2015
- December 2014
- November 2014
- October 2014
- September 2014
- July 2014
- June 2014
- May 2014
- April 2014
- March 2014
- February 2014
- January 2014
- November 2013
- October 2013
- August 2013
- July 2013
- June 2013
- April 2013
- March 2013
- February 2013
- August 2012
- May 2012
- February 2012
-
Categories
-
Meta
-
RSS links
Git packaging workflow
Seeing what has been posted recently in planet.d.o, I would like to share as well my thoughts and work-flow, and tell that I do agree with Joey Hess on many of his arguments. Especially when he tells that Debian fetishises upstream tarballs. We’re in 2013, at the age of Internet, and more and more upstream authors are using Git, and more and more they don’t care about releasing tarballs. I’ve seen some upstream authors who simply stopped doing so completely, as a Git tag is really enough. I also fully agree than disk space and network speed isn’t much of a problem these days.
When there are tags available, I use the following debian/gbp.conf:
[DEFAULT] upstream-branch = master debian-branch = debian upstream-tag = %(version)s compression = xz [git-buildpackage] export-dir = ../build-area/
On many of my packages, I now just use Git tags from upstream if they are available. To make it more easy, I now nearly always use the following piece of code in my debian/rules files:
DEBVERS ?= $(shell dpkg-parsechangelog | sed -n -e 's/^Version: //p')
VERSION ?= $(shell echo '$(DEBVERS)' | sed -e 's/^[[:digit:]]*://' -e 's/[-].*//')
DEBFLAVOR ?= $(shell dpkg-parsechangelog | grep -E ^Distribution: | cut -d" " -f2)
DEBPKGNAME ?= $(shell dpkg-parsechangelog | grep -E ^Source: | cut -d" " -f2)
DEBIAN_BRANCH ?= $(shell cat debian/gbp.conf | grep debian-branch | cut -d'=' -f2 | awk '{print 1ドル}')
GIT_TAG ?= $(shell echo '$(VERSION)' | sed -e 's/~/_/')
get-upstream-sources:
git remote add upstream git://git.example.org/proj/foo.git || true
git fetch upstream
if ! git checkout master ; then \
echo "No upstream branch: checking out" ; \
git checkout -b master upstream/master ; \
fi
git checkout $(DEBIAN_BRANCH)
make-orig-file:
if [ ! -f ../$(DEBPKGNAME)_$(VERSION).orig.tar.xz ] ; then \
git archive --prefix=$(DEBPKGNAME)-$(GIT_TAG)/ $(GIT_TAG) | xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz ; \
fi
[ ! -e ../build-area ] && mkdir ../build-area || true
[ ! -e ../build-area/$(DEBPKGNAME)_$(VERSION).orig.tar.xz ] && cp ../$(DEBPKGNAME)_$(VERSION).orig.tar.xz ../build-area || true
Packaging a new upstream VERSION now means that I only have to edit the debian/changelog, do ./debian/rules get-upstream-source so that I get new commits and tags, then “git merge -X theirs VERSION” to import the changes, then finally invoke ./debian/rules make-orig-file to create the orig.tar.xz. My debian branch is now ready for git-buildpackage. Note that the sed with the GIT_TAG thing is there because unfortunately, Git doesn’t support the ~ char in tags, and that most of the time, upstream do not use _ in version numbers. Let’s say upstream is releasing version 1.2.3rc1, then I simply do “git tag 1.2.3_rc1 1.2.3rc1” so that I have a new tag which points to the same commit as 1.2.3rc1, but that can be used for the Debian 1.2.3~rc1-1 release and the make-orig-file.
All this might looks overkill at first, but in fact it is really convenient and efficient. Also, even though there is a master branch above, it isn’t needed to build the package. Git is smarter than this, so even if you haven’t checked out upstream master branch from the “upstream” remote, make-orig-file and git-buildpackage will simply continue to work. Which is cool, because this means you can store a single branch on Alioth (which is what I do).