On Tue, 28 May 2019 at 21:20:50 +0100, Ian Jackson wrote:
> Simon McVittie writes ("Re: Survey: git packaging practices / repository
> format"):
> > xorg-team (e.g. mesa)
> > =====================
> >
> > Tree contains: upstream files from a git tag (not identical to the
> > upstream `make dist` tarball), sometimes with extra commits cherry-picked
...
> > Baseline upstream: changelog version => .orig tarball; files that
> > exist in git but not in the upstream tarball are compensated for by
> > extend-diff-ignore in debian/source/local-options
>
> I'm not sure if you know the answer to this, but I thought of a
> question or two:
>
> Apart from the extra files, these orig tarballs must be identical to
> the files in git, or dpkg-source would complain about the differences.
You might reasonably assume that, but no, they are not. mesa (and probably
other xorg-team packages) uses v1.0 dpkg-source format combined with
dh --with quilt, so deliberate Debian changes can be either direct
changes to the upstream source code, or quilt patches in d/patches,
or a mixture. Additionally, mesa uses d/source/local-options to ignore
files that only exist in the upstream git tag (which is what gets merged
into the packaging git branch), but not in the upstream `make dist` output
produced from that tag (which is used as the .orig tarball).
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).
Most other packaging git repository layouts that I've seen choose one
of those two design principles to follow (whichever one the maintainer
thinks is more important), and ignore the other one. For instance, many
Autotools packages have upstream release tarballs committed to their
upstream or upstream/latest branch, like I do for dbus: their maintainers
have chosen to follow the first of those design principles, because they
think the second is less important.
> So presumably when you say "changelog version => .orig tarball" you
> actually mean => some git tag, from which a tarball is made ?
No, I really do mean the binary artifact released by upstream from
`make dist` output, even though what's committed to the packaging
git repository does not correspond 1:1 to that. I'm aware that this
contradicts some of the assumptions made by both dgit and the 3.0 (quilt)
source package format.
smcv
