On Wed, 29 May 2019 at 14:14:09 +0100, Ben Hutchings wrote:
> On Wed, 2019-05-29 at 00:39 +0100, Simon McVittie wrote:
> [...]
> > My understanding is that this unusual difference between the .orig
> > tarball and what's in git is an attempt to "square the circle" between
> > two colliding design principles: "the .orig tarball should be upstream's
> > official binary artifact" (in this case Automake `make dist` output,
> > including generated files like Makefile.in but not non-critical source
> > files like .gitignore) and "what's in git should match upstream's git
> > repository" (including .gitignore but
> > not usually Makefile.in).
> [...]
>
> Perhaps we should update policy to say that the .orig tarball may (or
> even "should") be generated from an upstream release tag where
> applicable.
I couldn't immediately find anything in Policy that contradicts this.
devref ยง6.7.8 "Best practices for .orig.tar.{gz,bz2,xz} files" seems
to be the closest thing we have to policy on this? (That does currently
mandate use of upstream's official binary artifact unless there is a
very good reason not to, but perhaps priorities have shifted since that
section of devref was written and the reasons given there are no longer
as important as they used to be.)
I also tried dpkg-source(1), but that just describes the mechanics of the
formats, and not how they are meant to be used.
smcv
