From:
[email protected]
Hi!
I had another idea, that is way more elegant than the patch -n idea, and
works with current dpatch, without modifications. Actually, I have two
ideas, a simple one and a roboust one.
For both ideas, lets suppose we have three dpatches: 01_foo,
02_mailman_foo and 03_conflicting_foo. 01_foo does not conflict with
anything, but 02 and 03 conflict with each other. In
debian/patches/00list, you have all three listed. By default, 02 should
get applied, and 03 should not.
The simple idea involves DEB_BUILD_OPTIONS: If DEB_BUILD_OPTIONS has a "non-debian" part, then 02 should not get applied, and 03 should be
instead.
So, 02 has something like this:
case ${DEB_BUILD_OPTIONS} in
*non-debian*)
echo "Patchset deselected, skipping."
exit 0
;;
esac
Patch 03 has something like this:
case ${DEB_BUILD_OPTIONS} in
*non-debian*)
;;
*)
echo "Patchset deselected, skipping."
exit 0
;;
esac
This way, the user just has to add "non-debian" to DEB_BUILD_OPTIONS,
and he'll get a package that is built with patch #03 instead of #2.
The more roboust way involves dpatch log. Here, the idea is to check if
the other patch is applied or not, and if not, we apply ourselves. How
you construct a dependency tree from this, is up to you, but it is
doable in my opinion.
Checking wether a particular dpatch is applied goes like this:
if test "x$(dpatch log 02_mailman_foo)" = "x"; then
# patch #2 is not applied
else
# patch #2 is applied
fi
However, since this is a very esoteric case, I will not add this to any
of the default templates. However, now that I came up with something
that sounds like a clean idea, I might document it.
If documented, would you agree to this bug getting closed?
Cheers,
--
Gergely Nagy
--
To UNSUBSCRIBE, email to
[email protected]
with a subject of "unsubscribe". Trouble? Contact
[email protected]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)