diff options
| author | Richard Purdie <richard.purdie@linuxfoundation.org> | 2012-03-01 23:38:00 +0000 |
|---|---|---|
| committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2012-03-02 16:13:31 +0000 |
| commit | f0fc47aea37793a62c43f10eea27ca014c420924 (patch) | |
| tree | 7442376a81bc2edc8defec8e689c903b7225fa4e /meta/recipes-support | |
| parent | b82c216c1ee8e2a009e87856b7adad08f7f50482 (diff) | |
| download | openembedded-core-f0fc47aea37793a62c43f10eea27ca014c420924.tar.gz openembedded-core-f0fc47aea37793a62c43f10eea27ca014c420924.tar.bz2 openembedded-core-f0fc47aea37793a62c43f10eea27ca014c420924.tar.xz openembedded-core-f0fc47aea37793a62c43f10eea27ca014c420924.zip | |
lib/oe/patch.py: Fix and improve PatchTree() resolver logic
Currently, if PATCHRESOLVE is user and and PatchTree() is being used, you can
get backtraces if patch application fails. This is because even in the failure
case, self._current is incremented, meaning second time around, there are array
range issues.
This patch changes the code so _current is only incremented upon successful
patch application, thereby resolving this failure.
Secondly, if you bitbake -c patch -f a recipe using PatchTree(), the
clean method was unimplemented leading to patch failures.
The other part of this patch changes the logic so a series file and
set of applied patches are maintained in a quilt like fashion. This
means a the Clean method can be implemented correctly and rerunning
the patch task of an existing patches source now works reliably.
[YOCTO #2043 partially]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/recipes-support')
0 files changed, 0 insertions, 0 deletions