* Teemu Likonen: >> That would be one possible way of implementing it. I'd be satisfied >> with that, and it's in the spirit of the way Debian tries to >> standardize on interfaces that don't unduly limit implementation. > > To add up to this suggestion: > > If some patch system is used, there would be mandatory targets > like "patch", "patch-new" and "patch-save" in the debian/rules. These > can probably be included from /usr/share/quilt/quilt.make > or /usr/share/dpatch/dpatch.make or similar. Also a target > like "unpack" must be available if upstream sources are in compressed > form inside the orig.tar.gz.
You still need to deal with corner cases such as copying files before patching them (unpacking the tarball is just a special case of that). Personally, what I want to see is something that allows me to switch to a new upstream version, to add an additional patch the top of the stack (that's the easy case), and to add one at the bottom of the stack. The latter is the case relevant to security updates for which there are suitable upstream patches. If there are conflicts, I really want a regular three-way merge (like in "git rebase --interactive"), not the two-way merge plain patch provides. It appears that both quilt and guilt do not meet the three-way merge requirement. I'm not sure about StGIT. Some Mercurial docs suggest that it's got something with queues and three-way merging, but it's still considered experimental. Until these tools issues have been resolved (in whatever tool, if the workflow has been hashed out in one tool, it's relatively straightforward to port it), those who despise patch queues in Debian have my full support. If this has actually been addressed in a satisfactory manner in one tool, I'd be happy to hear about it. And that's why I think that for the time being, Russ' policy proposal is the right thing to do (at least the debian/README.source part, the "patched" target is problematic and doesn't add much). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]