I noticed a problem here which was caused by the nonzero fuzz factor as
it is used in Yocto Pyro.
Suppose there are two patches A and B, and they do touch the same parts
of the code, so they do influence each other.
The intended patch application order is A, then B. But due to an error
in a bbappend the actual order is B, then A. I'd expect an error when
bitbake attempts to patch with B first (because A's changes are
missing). However, what actually happened that an error came when
bitbake tries to apply A.
Here's why? Patch A adds exactly one line. This extra line happens to
affect the context area in B. And since the default fuzz factor is 2,
this one line difference in B's context is suppressed. As a result, I
get the confusing error output that A could not be applied. If I force
the fuzz factor to be 0, then everything happens as expected - an error
occurs when trying to apply B first.
I was surprised that Yocto does not use fuzz factor 0 by default. The
case above demonstrates how this can lead to confusing errors. Or worse,
recipes might even build but then cause subtle runtime errors...
Is there a reason why the default fuzz factor isn't 0? Is it just
because of the large amount of work required to fix all these patches
that won't apply without a fuzz factor?
Openembedded-core mailing list