Re: let missing-debian-source-format lintian tag be a warning!
On Tue, Jul 15, 2014 at 10:42:15AM +0900, Charles Plessy wrote:
> Le Tue, Jul 15, 2014 at 03:26:30AM +0200, Mattia Rizzolo a écrit :
> > In fact I'm wondering what is the rationale to stay with the 1.0 format, given
> > all the benefits of the 3.0 (quilt) format:
>
> Hi Mattia,
>
> I am not a big fan of the 3.0 (quilt) format because it imposes a patch system.
> In particular, this format does not make much sense when managing the source
> package with Git.
Having followed it up after last year's DebConf, I've been absolutely
sold on git-dpm, FWIW; I find it does a great job of making the patch
queue pleasant to maintain in a git-native style while providing a nice
easy-to-read export to 3.0 (quilt) - that is, you don't actually use
quilt manually. At that point 3.0 (quilt) makes a lot of sense to me as
an automatable serialisation of upstream + patch queue + packaging with
a minimum of package-specific code, and the only way in which it imposes
a patch system is that the tools I'm using need to export to it (which
is really not that much more than git format-patch with some care about
file names, so no big deal, and people can still inspect and modify my
source packages without my fancy tools).
Getting my head around git-dpm was the tipping point for me to spend
some time converting my packages out of bzr or older systems, and now I
find myself actively seeking out things I can do with it, which seems to
me to be a quite remarkable property in this sort of tool especially
given that I started out not being desperately fond of git. And I was
going to need some kind of patch queue against upstream in many cases
anyway, so it's not as though it adds some new overhead that I wouldn't
have had to care about without 3.0 (quilt). A good number of my
packages are now just fancy branches of upstream's git repository, which
is IMO right and proper.
gbp-pq is of course fairly similar. I looked at both although I admit
that I only experimented extensively with git-dpm. They both look like
they should get the job done, but git-dpm just seemed more featureful
and polished to me based on its documentation, and I really like the way
it handles the results of rebasing the patch queue.
For completeness, the only downsides I've encountered after six months
or so of using git-dpm are:
* If you have a big patch queue then it can create rather a lot of
commits, since changes deep in the queue cause everything after them
to be rebased and the tip of the rebased branch merged into master.
This is fine in gitk or similar, and it's a clever and useful way to
keep track of various versions of a rebasing branch while keeping the
end result fast-forwarding, but it can be a little puzzling in things
like a gitweb shortlog.
* It (perhaps necessarily?) doesn't quite do an exact round-trip of
debian/patches/ when you first convert to it, since it exports
patches using git format-patch and so changes the format of patch
headers a bit. I decided that I didn't find the changes
objectionable for my own packages, but it's not entirely obvious how
things would work if you were to try to make this scheme work for all
3.0 (quilt) packages in dgit, where you want to make sure to
round-trip cleanly.
* Not really git-dpm's fault, but the bug fixed in
http://www.spinics.net/lists/git/msg234123.html caused some confusion
on a couple of occasions when rebasing against new upstream releases.
Anyway, worth a look if you haven't already.
--
Colin Watson [cjwatson@debian.org]
Reply to: