Idea: sbuild/pbuilder "--dgit" option

[Ian Jackson]

Johannes Schauer writes ("Re: Idea: sbuild/pbuilder "--dgit" option"):
> sbuild already has an option to do just that:
>     $ sbuild --dpkg-source-opts="-i\.git/ -I.git" ...
> Or by putting the following in the config file:
>     $dpkg_source_opts = ["-i\\.git/", "-I.git"];
> (hope I got all the backslash escaping right there).

Right.

I wonder if a --dgit option ought to (perhaps optionally) do something
different about package clean targets.  Does sbuild already have an
option to use `git clean' (and maybe `git reset') instead of the
package clean target ?

I always do all my builds-for-upload with dgit --clean=git-force (aka
dgit -wgf) now; this is pretty much a requirement when working on a
package whose maintainer is not using dgit, because package clean
targets are often troublesome.

> Unfortunately, typing this is much more involved than just putting --dgit

Precisely.

>  but maybe we can do even better. I wonder:
>
>  - are there other git-based workflows than dgit which need these cleaning
>    options? Then the option name could be picked to be more general and not
>    dgit specific

I'm not aware of any but there are so many gitish workflows in Debian
that it's hard to say for sure.  I think it is quite unlikely.  Here
are some arguments for thinking this is unlikely:

 * Any git-based Debian workflow needs to ignore .git at least.  There
   is no convenient way to do exactly that: the options to do exactly
   that (as seen above) are obscure, requiring a careful reading of
   the docs.  Conversely, there is the -i (without value) option which
   is documented with vague but encouraging wording in dpkg-source(1)
   and which many tool authors have discovered and used already.

 * For maintainers using git-based workflows, the lack of .gitignore
   (or updates to .gitignore) in source packages is invisible, because
   such maintainers never work with the source packages for their own
   packages.  (There was not really a viable non-maintainer git
   workflow, before dgit.)

 * dgit is the only tool I'm aware of which actually insists, and
   checks, that the git tree and the source package are equivalent
   (for any value of equivalent).  All the other tools that do
   git<->dsc conversions are `open loop', and conversions are
   typically unidirectional.  So the .gitignore anomaly would not be
   detected by other tools.

If you want a more generic option name `--faithful' would be a good
one, if perhaps rather tendentious :-).  Personally I think `--dgit'
is a good one because if we discover that there are other things that
would work better if the builder did them differently, we can have a
single option where the user declares their workflow.

>  - is there a reliable and future-proof way for sbuild/pbuilder to
>    auto-detect that they are working on a dgit package? Maybe by
>    examining the Vcs-Git field? Then they could pick the right
>    options for dpkg-source automatically.

That's a nice idea.  However, "we are using dgit" is not a property of
a package.  It's a property of the user's workflow.  The same package
(and perhaps even the very same git branch) can be worked on, at one
time, by a user who is not using dgit, and at another time by a user
who is.

For example, a dgit-using NMUer may work on packages with many
different (or totally absent) Vcs-Git fields.  They may even do a
dgit-based NMU based on a history they found on alioth, or something.

Even if we restrict ourselves to maintainers[1], a maintainer who uses
dgit also needs to store their un-uploaded git commits somewhere.  The
dgit git server does not do this (yet).  So often that will be the
maintainer's own server, or a team repo on alioth.

[1] dgit is so compelling for the NMU use case (particularly, for an
NMU campaign) that the fact that need to wrap your build with dgit is
only a minor inconvenience.

> Otherwise (and also being a dgit user myself) I'm open to adding a --dgit
> option to sbuild. I'd just want to hear your ideas about the above first
> because I don't want to add an option just to deprecate it one release later.

These are all good questions.  Please do ask more probing questions.
Before anyone actually implement this I would also like to hear from
at the very least the pbuilder maintainers.

Ian.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.