DEP14 policy for two dots

[Ian Jackson]

Nish Aravamudan writes ("Re: DEP14 policy for two dots"):
> On 09.11.2016 [23:38:30 +0000], Ian Jackson wrote:
> > Can you confirm what approach you have taken to the representation of
> > Debian source packges as git trees ?  I would like to encourage you to
> > use a representation which is compatible with dgit.
> 
> I think we are fairly compatible. The only difference would be the
> actual git commits themselves, I think, because we treat Launchpad as
> our canonical source of information, while dgit uses the Debian archive
> (aiui).

dgit can work on Ubuntu too, in a readonly mode.  (It would be nice to
make `dgit push' work on Ubuntu but that requires a suitable git
server, and some configration on the dgit client side.)

> > That is, the git tree object should look exactly like the results of
> > `dpkg-source -x', except that the .pc directory which dpkg-source
> > creates for `3.0 (quilt)' packages is deleted.
> 
> Yes, we use `dpkg-source -x --skip-patches` on an appropriate DSC file
> for both Debian and Ubuntu publications. That is the tree we commit with
> appropriate parents (as determined by Launchpad's publication history
> and the d/changelog file).

The --skip-patches is a vital difference.
Has the decision to use --skip-patches been definitively taken ?

I would like to beg you to reconsider this, in the strongest possible
terms.  --skip-patches generates a patches-unapplied tree.

A patches-unapplied tree:

 * produces confusing and sometimes misleading output from
   git grep, or (even if appropriate history is available)
   with git blame;

 * cannot be used with `git cherry pick <some upstream bugfix>';

 * cannot be used as a basis for `git merge upstream/<whatever>';

 * requires that the user not say `git diff upstream/master'
   but rather that they read patches in debian/patches;

 * cannot be directly edited by the user;

 * leaves the git tree dirty after every build with dpkg-buildpackage
   no matter how careful or tidy the package's build system.

For these reasons, dgit's interchange format is patches-applied
trees.  (dgit 2.x supports a maintainer using patches-unapplied branch
and converts it for publication during dgit push.)

I understand why many Debian maintainers like to use patches-unapplied
trees.  They make a reasonable archival format for a maintainer who:

 - understands the `3.0 (quilt)' format very well;

 - understands their own quilt/git workflow;

 - has chosen to use (and to learn) a specific Debian git workflow
   tool such as git-buildpackage;

 - is willing to read interdiffs occasionally.

These are not properties we should expect of all our users and
downstreams.  They are not even properties we should expect of all our
future developers.

dgit (and git-dpm) show that it is possible to work with, and
interchange, patches-applied git trees.

> > It would probably be nice if the commit history structure of imported
> > source packges was a bit like the dgit imports.  Or better if it were
> > identical, but that's probably too much to ask for because you
> > probably do not want to make dgit 2.x a dependency for your project.
> 
> I will spend some time next week looking at what dgit imports look like,
> but I'm guessing they are not the same currently.

If you are making patches-unapplied trees I think you cannot possibly
be representing the quilt patch stack of a `3.0 (quilt)' source
package as a series of git commits.

Representing a `3.0 (quilt)' package that way is desirable, as it
means that `git blame' and `git log' can be used to see which patches
do what.

> > I encourage you to try out dgit 2.x and see what you think of its
> > efforts for some existing source packages.  Eg `dgit clone libvirt
> > stretch'.
> 
> I will do this soon, to compare, thanks!

The dgit_2.11_all.deb binary package in Debian unstable is very likely
to be directly installable and useable on all supported Ubuntu
versions.  So I think you can just `dpkg -i && apt-get -f install'
(or apt install ./dgit.deb, if your apt can do that).

Anyway, thanks for your consideration of my points, above.

Regards,
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.