[OE-core] Stricter fuzz factor when patching?

[Carlos Rafael Giani]

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?