To add a different story to git-buildpackage, here are a couple of stories of
updating packages to new upstream versions that I hope are helpful. I'm
concentrating on the updating stage here because the importing/creation of a
new git repo for packaging should be a trivial step (if it's not, there's
something very wrong), while the process of updating to a new upstream version
is always going to be the step that requires thought.
My approach here could perhaps be described as a lowest common denominator
approach but my intention here is just to keep it simple. I feel that we have
a tendency to overthink our solutions to deal with every single corner case
imaginable and as a result we construct extraordinarily complex wrappers
around wrappers around helpers around wrappers with command line options for
everyday use that make a PhD thesis look short. They become a massive barrier
to new contributors and, much of the time, don't help us as much as we'd like
to believe.
So... in summary, below you will find:
* git for the source package: I need to work on the source so the full
source needs to be there.
* git-buildpackage imports tarballs, builds and tags things.
* quilt patches are managed by quilt. (If I'm sending patches to an
upstream, I'm probably attaching them to a bug tracker anyway, so I can
just attach the file from debian/patches/ -- if I'm importing a patch from
upstream, I can use either `quilt import` or `patch` or even just copy
it into debian/patches/. And I do this so rarely that it's not worth
learning lots of new tools to cover the case where the exact same
patch has been applied both upstream and in the package)
I'm sure there are some whose interactions with upstreams, workflows and
packages warrant more sophistication in the packaging helpers. Great! Let's
not push very complicated helpers at people who don't necessarily need them.
Let's not require everyone to become a git guru to be able to work on a simple
package. Ideally, let's try to make sure that it actually doesn't matter which
of the 3 workflows we've recently outlined are used because the artefacts in
the git repo on alioth are the same in all cases.
(Thanks for the inspiration, Barry)
## i18nspector
I have explicitly set the keyid in ~/.gbp.conf and have a debian/gbp.conf
requesting signed tags so I am prompted for my passphrase during importing to
sign the tags. I know that this upstream is sane and won't have put crap into
the tarball that I need to keep out of git so I can just let pristine-tar
commit it straight away.
$ uscan
[…]
$ git-import-orig ../i18nspector-0.16.tar.gz
[…]
(yes, I should learn to type `gbp import-orig` instead)
I like to check what crazy^Wcool things upstream has been doing in this
release, and also to look for new files, new copyright statements, bugs that
are fixed etc. The following is why I really like having the upstream source in
the git repo rather than having it separate.
$ git diff --stat upstream/0.15 upstream/0.16
[…]
44 files changed, 1571 insertions(+), 717 deletions(-)
$ git diff upstream/0.15 upstream/0.16
This upstream is good to work with -- he makes packaging easy. I don't
actually have any patches to update anyway. I did notice in my review that the
new version fixes a bug.
$ dch -v 0.16-1 "New upstream version."
$ dch --closes 753946
$ git commit debian/changelog -m"Add changelog for new upstream version"
I always do out-of-tree builds -- it's a way of avoiding the different
behaviour of the vcs build helpers and it's also means that if I've got stuff
removed in the clean target I don't have to worry about making the tree dirty.
I could (should?) probably figure out the correct incantation for git-
buildpackage to have this happen for me as Barry did (`--git-export=WC` by the
looks of it)... but I just run what amounts to `dpkg-buildpackage -nc -S -us -
c; sbuild ../foo.dsc` (yes, I have a short script that does that for me in the
same way as everyone has enormously complicated aliases for svn-bp -- it also
suppresses signing of the test builds). sbuild is configured to run lintian for
me too.
Now because I know this particular upstream produces good releases and the diff
looked pretty safe, I'll take an "optimistic" approach here and assume that
what I've got is going to be ok and build and tag at the same time. I can
always come back and `git commit --amend` if I need to later since I've not
pushed this work:
$ dch -r unstable
$ git commit debian/changelog -m"Prepare changelog for release"
$ git-buildpackage --git-tag
[…]
As Barry noted, gbp throws up a dbus notification that this has finished. I
quite like that, especially when I'm working on packages that take a long time
to build (lots of C++ stuff or piles of documentation that requires all of
texlive to be installed etc). Yes, Barry, you can disable that with --git-
notify=off (or in your ~/.gbp.conf).
Now this package has some
