Re: a poll for Dgit workflows

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Marco d'Itri writes ("Re: a poll for Dgit workflows"):
> I cannot comment on other the workflows of specific tools, mostly 
> because I have never managed to find one that would solve some problems 
> that I have, but my own packages do not require anything like that, not 
> even quilt. E.g.:

Thanks for sharing.

But this doesn't really do what I am trying to achieve:

  But I think that someone who knows how to use git should be able to
  get the source code for a package in Debian, as a git branch, and
  modify that source code, and share it, and so on, without needing to
  deal with quilt, or learn any of dpkg-source --commit, git-dpm, gbp,
  git-debcherry, debian-git-patch-spoogler, Uncle Tom Cobbly and all.

Implicitly I meant that they also shouldn't need to know who the
maintainer is, or look it up (unless they want to talk to the
maintainer, of course).

I also mean that the user should get the source code for the package
in the archive.

So problems for your example package are:

> git clone git://anonscm.debian.org/users/md/kmod.git
> cd kmod
> # if you do not have the upstream source archive then you can make your own

1. You've missed out this step.  (dgit arranges for you to have an
upstream source archive, although this is not needed for
entirely-git-based workflows using dgit-compatible git branches.)

I guess you expect that the user should go to ftp.debian.org and
download some tarball from there ?  Which one ?

> git checkout v22

2. How does the user know that this is what they should do ?  Where
did this `v22' come from ?  (The Vcs-Git field in debian/control gives
the repo location, at least.)

3. After doing this, the source code is not the source code that I am
running, because this provides a patches-unapplied branch.

This means that `git-grep' lies.  If the user tries to build the
package, they may end up with a build error, or an unpatched version.

In the best case the build tool they use notices, and applies the
patches - but then the build has made their tree dirty by modifying
the source code, which is not what a git user would expect.

> cd ..
> tar cJf kmod_22.orig.tar.xz kmod
> cd kmod
> git checkout master

4. How is the user supposed to know to do these things ?  Maybe there
is a README somewhere with some runes in.  But I want the user to Just
Have The Source Code In Git.

> # and now you can start hacking
> echo meh >> TODO
> # if you do not know about this step then dpkg-buildpackage will 
> # helpfully tell you about it
> dpkg-source --commit

5. Of course a git user would already have committed their changes.
(Probably, actually, the git user has given up in disgust, because of
the unapplied-patches problem.  But let's pretend that this is not so.
Perhaps the package had no patches beforehand.)  So now they are asked
to commit them again using a different and far-inferior VCS.

Furthermore this dpkg-source commit makes their git tree dirty.

> There is nothing here but pure git and standard Debian tools.
> 
> Also, considering that most Debian packages nowadays use the 3.0 quilt 
> format I do not think that asking developers to use quilt is an 
> excessive burden.

I disagree.  quilt is a very poor VCS.

Ian.