Re: Git packaging workflow discussion on planet.d.o

[Guido Günther <agx@sigxcpu.org>]

On Thu, Apr 04, 2013 at 09:38:36AM -0700, Russ Allbery wrote:
> Jean-Christophe Dubacq <jean-christophe.dubacq@ens-lyon.org> writes:
> 
> > Yesterday, however, I just had the case of a project with no tarballs
> > (as the library I wanted to package is part of a larger project, it's
> > not released independently). I stumbled (too long) on having a good
> > workflow for this (I ended up tagging myself the upstream tree).
> 
> Using git archive to generate a tarball from upstream is something that I
> do in some cases as well.  It all depends on upstream's release process.
> I default to using released tarballs if they exist and are useful, but I
> fall back to git archive when they're not.
> 
> For example, for OpenAFS, upstream releases the software as two separate
> tarballs, one with the code and one with the documentation.  I don't find
> this a useful organizational structure for the Debian packaging, nor are
> they split in the upstream repository, so I use git archive to generate a
> tarball instead.  This means that the tarball Debian uses doesn't match
> upstream, which is a drawback, but in this case I know upstream practices
> well enough to know that it shouldn't matter.
> 
> The only thing to be aware of with git archive is that you still want to
> use pristine-tar, since otherwise you either have to redownload the
> *.orig.tar.gz from Debian or you have to keep it around somewhere.
> Running git archive twice on the same tag won't produce the same file
> reliably.

git-buildpackage can handle the tarball generation + pristine tar
interaction with the '--git-pristine-tar-commit' option. It will then
generate the tarball and commit the delta back to the pristine-tar
branch.
Cheers,
 -- Guido