Iustin Pop <iu...@k1024.org> writes: > Furthermore, by standardising on quilt patches, I hope that we will move > away from directly patching upstream source in the debian diff.gz, which > I find very sloppy work.
If patches to the upstream source are maintained in Git or some other full-featured revision control system with merging and similar features, serializing those changes into a set of patches turns out to be rather obnoxious and tedious without any clear benefit to the package maintainer, even with the assistance of tools like TopGit. I'd be happy to use 3.0 (git), but the patch management features of 3.0 (quilt) only seems helpful in some specific contexts with workflows that are already separating out the patches for other reasons. I will use it for rssh, for instance, since the maintainer has stopped issuing new releases but the various distributions exchange patches and it's nice to have them already broken out. But for openafs, where I cherry-pick upwards of 20 or 30 changes from the upstream stable branch routinely and often have to do moderately complex merges with Debian-specific changes, trying to serialize those as quilt patches makes no sense to me and would just consume time that I could better use for other Debian work. That being said, the 3.0 (quilt) format is to a degree just a more complex version of the 1.0 format that supports applying the patches automatically, so while there are still tool problems (like the one Norbert noted, or the fact that Lintian is not yet properly checking the patches for all the issues that it checks the 1.0 patch for), it does seem likely that we'll be able to get to a point where using it is as easy as using 1.0. For Git-maintained packages like openafs, that would mean ignoring all the patch management features and letting it generate a single combined Debian diff analogous to the existing 1.0 diff from the patched upstream source maintained in Git. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
