Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)
Adam Borowski writes ("Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)"):
> On Tue, Sep 17, 2013 at 07:02:04PM +0100, Ian Jackson wrote:
> > Or you could simply ignore the format `3.0 (quilt)' thing entirely and
> > allow it to automatically accumulate one diff per upload, and
> > presumably clean it out occasionally.
>
> There's more to "3.0 (quilt)" than just quilt:
> * multiple tarballs (good)
> * a way to include binaries without uuencode (good)
> * upstream debian/ is nuked (sometimes good, at worst a minor waste of
> space and a minor inconvenience)
Right.
> Here's one way:
> rm -rf .pc debian/patches
> echo single-debian-patch >>debian/source/options
>
> The rm needs to be repeated, either in the "clean" target or perhaps by
> dgit.
I don't think removing .pc and debian/patches will DTRT because
dpkg-source -x will produce a directory containing them. dgit's idea
of "the source tree from the source package" is "whatever dpkg-source
-x produces".
I think even if you put single-debian-patch in debian/source/options,
you'll find that dgit still needs to make the spurious commit on your
git head to represent the results of dpkg-source --commit (that is, to
represent the changes to .pc and debian/patches.
It would be nice if there were a source format that:
* Could represent every change to a source tree (including the
deletion of upstream files!)
* Did not insist in including droppings in the trees it manages.
* Supported multiple tarballs.
> This turns "3.0 (quilt)" into "3.0 (sane)" and allows using version
> control without having to go out of your way to work around quilt.
Single-patch "3.0 (quilt)" is still IMO insane. The droppings in .pc
and debian/patches (which require workarounds in dgit) also mean (for
example) that a debdiff of a one-line change contains a giant pile of
poo.
Ian.
Reply to: