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
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Reply via email to