Re: git, debian/<version> tags, dgit - namespace proposal

[Simon McVittie <smcv@debian.org>]

On 16/11/15 22:57, Brian May wrote:
> In what way does your use differ from the debian/<version> tag in
> DEP-14?

For a 3.0 (quilt) package, debian/1.2.3-4 is whichever the maintainer
finds most useful for their particular workflow, either "patches
applied" or "patches unapplied". The version with patches unapplied
often makes it considerably easier to merge new upstream versions when
using something like gbp pq.

The tagged version might also differ from the archive in other ways, if
the maintainer's workflow requires that. For instance, some packages
have debian/source/local-options in their git repository; by definition
this file is not included in the uploaded .dsc. Other packages
(particularly those where upstream doesn't use git) add a /.gitignore in
the packaging git repository, but exclude it from the Debian diff,
because it is inconvenient to apply as a patch and is not functionally
necessary. I've also seen packages that base their packaging repository
on the upstream git repository, not on the orig tarball (so they don't
have Autotools-generated files like /configure), but use the orig
tarball (which does have those files) as the basis for uploads. This
normally works, because dpkg-source -b ignores deletions.

Ian is looking for a name for a tag that specifically means the version
that exists in the archive, with patches applied, no local-options or
other ignored changes, and all files that exist in the orig tarball (and
are not removed by patches) present, even if that is not actually what
the maintainer normally works with in git.

Some other possible colours for this bike shed:

dpkg-source/[<distro>/]<version>
dsc/[<distro>/]<version>

Regards,
    S