Hi, 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 case) How does that sound? (Thanks to mrvn who suggested me the ideas) Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
