Re: dgit and git-dpm (was Re: Standardizing the layout of git packaging repositories)
Simon McVittie writes ("Re: dgit and git-dpm (was Re: Standardizing the layout of git packaging repositories)"):
> On 29/10/14 12:08, Ian Jackson wrote:
> > The contents of the default ignore
> > list is in dpkg-source, but it is not enabled unless the caller says
> > -I. git-buildpackage passes -I.
>
> To be completely clear (because I misread it twice in a row), you mean
> that it is not enabled unless the caller uses «-I» with no argument,
> which git-buildpackage does? (No literal strings «-I.» anywhere.)
Yes.
> This seems appropriate for the model you encourage with dgit, where the
> git tree is identical to the unpacked .dsc.
Right.
> dpkg-source's -I is currently equivalent to [lots of stuff]
Blimey.
> I suspect that the reason .gitignore is included in that list is so that
> maintainers who build from git, but whose upstream does not, can drop a
> /.gitignore into their git tree, as the maintainer of xwit appears to
> have done, without it being managed as a Debian patch to the upstream
> source code. It is necessary that it appears at top-level, because
> otherwise it wouldn't have the desired effect; but it is an
> implementation detail of how the Debian maintainer chose to set up their
> VCS, so presumably they don't consider it to be something that should be
> in the .dsc (where it would have to be handled as a quilt patch, or as
> part of the diff.gz for format v1).
Yes.
I don't think there is any problem with including it as a quilt
patch.
> Obviously, this directly conflicts with dgit's view of the world, in
> which the git repository and the unpacked .dsc correspond 1:1.
Yes.
> I think debian/source/local-options is going to be another potential
> pain point for dgit: it is deliberately not included in a .dsc because
> that would defeat the object of those options being local.
If you have that file in your git branch then the git branch is indeed
unsuitable for use with dgit (and dgit will detect this when you try
to push).
> In non-native packages, if there's a /.gitignore in the orig.tar.gz, I
> think gbp would leave it alone? (The only other option would be to add a
> quilt patch that explicitly removes it, or add a patch-band for it in
> the v1 diff.gz, which seems unlikely.)
I recently did (with dgit) a maintainer upload of adns, which is a
non-native 1.0 package, whose upstream source has .gitignore.
Of course the upstream .gitignore doesn't mention files generated by
the Debian packaging.
So the .diff.gz for adns includes a patch to add the relevant
Debian-specific things to .gitignore. This doesn't seem to cause any
kind of problem.
> On 29/10/14 09:47, Dimitri John Ledkov wrote:
> > Ideally "packaging .gitignore" would be in debian/gitignore, but I
> > don't know if that will work.
>
> debian/.gitignore (which is presumably what you meant) can only be used
> to ignore files under debian/. So you can do
Indeed. And even if there's nothing else, dh tends to create
`/build-stamp'.
> I suspect that a lot of upstreams have a .gitignore, but don't put it in
> their tarball releases, on the basis that the tarball is not a git
> checkout. I certainly don't, although I'm considering it (it would make
> it easier for distro maintainers to cherry-pick patches that happen to
> add a new binary to .gitignore).
Yes.
If you have an upstream who think that their tarballs ought to be
different to their git trees, you are always going to have these kind
of difficulties.
You have two options:
A. Base your Debian packaging solely on the upstream git,
and arrange for your debian/rules to run autogen.sh et al.
You'll have to synthesize a .orig.tar.?z (eg with git-archive).
B. Base your Debian packaging on upstream tarballs.
Reasons to prefer A:
* You can easily make releases from any upstream git commit even if
upstream don't provide a tarball. (With B. you might have to
construct a fake upstream tarball, hopefully using the same scripts
that upstream do...)
* Cherry picking from upstream git works properly without
conflicts.
* With B it is difficult to always build from the `sourcest source'
(eg configure.ac and Makefile.am) because that might result in
pointless noise changes to files like configure - changes which the
Debian build and packaging workflow has trouble with.
Reasons to prefer B:
* The Debian .orig.tar.?z is identical to upstream's.
* The Debian source package is easier to use in semi-broken
environments, by disabling eg autogen.sh.
Ian.
Reply to: