When we do do_patch, we start by trying to use quilt to undo any
previously applied patches, so that all the patches can be applied
again. Unfortunately there's a few bugs causing this to never really
work.
First of all, util.shcmd returns None for failure and True for
success. So if quilt pop succeeds, we raise an exception claiming that
it failed... Now, if quilt pop fails for some reason, it is likely to
leave the filesystem mostly intact - in particular, .pc/applied-patches
is unlikely to disappear, which means we end up in an infinite loop
running quilt pop over and over.
It turns out that quilt pop does fail to reverse certain patches if
the ${PATCHDIR}/series file has been removed; at first I thought it was
when the patch has a header above the actual diff, but I've also found
counterexamples to that hypothesis. Regardless of the exact
circumstances where quilt uses/needs that file, we might as well
postpone its deletion a little.
Finally, since quilt pop accepts -a meaning "Remove all applied
patches.", we might as well use that and avoid the risk of an infinite
loop as well as spawning fewer children.
The changes in fetch.oeclass are just to propagate the failure from
patch_init upwards. The last return is changed to a 'return True' -
though our PythonFunction class treats both None and True as success,
True better contrasts the two return Falses. (The initial assignment to
uri was a dead store, and even a little confusing since patch_init used
to either (implicitly) return None or raise.)
With this, I can do
oe bake world -t patch # from clean state
find tmp/stamp/machine -name do_patch -delete
oe bake world -t patch
with only gconf, libtasn1 and luacheia5 failing in the second run - all
because they have some do_patch pre/postfunc which does something that
interferes with reversing the patches, and there's nothing we can do
about that. Without this patch, the above exercise runs into the
infinite loop rather quickly, so I can't really tell how many recipes
are "vulnerable" to that.
When we do do_patch, we start by trying to use quilt to undo any previously applied patches, so that all the patches can be applied again. Unfortunately there's a few bugs causing this to never really work.
First of all, util.shcmd returns None for failure and True for success. So if quilt pop succeeds, we raise an exception claiming that it failed... Now, if quilt pop fails for some reason, it is likely to leave the filesystem mostly intact - in particular, .pc/applied-patches is unlikely to disappear, which means we end up in an infinite loop running quilt pop over and over.
It turns out that quilt pop does fail to reverse certain patches if the ${PATCHDIR}/series file has been removed; at first I thought it was when the patch has a header above the actual diff, but I've also found counterexamples to that hypothesis. Regardless of the exact circumstances where quilt uses/needs that file, we might as well postpone its deletion a little.
Finally, since quilt pop accepts -a meaning "Remove all applied patches.", we might as well use that and avoid the risk of an infinite loop as well as spawning fewer children.
The changes in fetch.oeclass are just to propagate the failure from patch_init upwards. The last return is changed to a 'return True' - though our PythonFunction class treats both None and True as success, True better contrasts the two return Falses. (The initial assignment to uri was a dead store, and even a little confusing since patch_init used to either (implicitly) return None or raise.)
With this, I can do
oe bake world -t patch # from clean state find tmp/stamp/machine -name do_patch -delete oe bake world -t patch
with only gconf, libtasn1 and luacheia5 failing in the second run - all because they have some do_patch pre/postfunc which does something that interferes with reversing the patches, and there's nothing we can do about that. Without this patch, the above exercise runs into the infinite loop rather quickly, so I can't really tell how many recipes are "vulnerable" to that.