Re: Git packaging workflow discussion on planet.d.o
Jean-Christophe Dubacq <email@example.com> 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
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>