Re: How to cope with patches sanely
- To: email@example.com
- Subject: Re: How to cope with patches sanely
- From: Florian Weimer <firstname.lastname@example.org>
- Date: Sun, 24 Feb 2008 17:29:42 +0100
- Message-id: <[🔎] email@example.com>
- In-reply-to: <firstname.lastname@example.org> (Teemu Likonen's message of "Thu, 31 Jan 2008 12:31:36 +0200")
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
* 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).