Re: New source package formats now available
On Wed, 25 Nov 2009, Russ Allbery wrote:
> I've considered using TopGit to generate a real quilt patch set, but
> it's kind of complicated and I'm not convinced that the work required to
> generate the exported patch tree even with TopGit is really worth it.
> Given that, for packages currently maintained in Git, 3.0 (quilt) is
> extra complexity over 1.0 that doesn't seem to be buying me very much.
Why not generate a single patch then instead of a patch set? If that
single patch contains an header explaining why it's not split and
where you can review the changes in a more friendly manner you can
have all the other features of the new format and yet the the situation
improve wrt to knowledge/advertisement of our debian-specific changes.
> It would be nice, however, to have the other features of the 3.0 format
> (including binaries in the debian directory, not shipping the debian
> directory as a patch, using multiple upstream tarballs, using
> bzip2-compressed upstream tarballs) without having the quilt-like patch
> system in play.
Even if quilt supports multiple patches, you are not forced to use
multiple patches. You can get the same than a 1.0 source package with a
single patch that you regenerate each time.
I would be ok to add support for this in "3.0 (quilt)":
- add an option "--single-debian-patch" that could be set in
debian/source/options. With this option dpkg-source would update
debian/patches/debian-changes (instead of debian-changes-<ver>)
- support a debian/source/debian-patch-header that would be used
as header of the automatic patch (debian/patches/debian-changes in this
How does that sound? (Thanks to mrvn who suggested me the ideas)