On Thu, Apr 04, 2013 at 09:38:36AM -0700, Russ Allbery wrote: > Jean-Christophe Dubacq <jean-christophe.dub...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130405110458.ga21...@bogon.sigxcpu.org
