Quoting Alexander Kanavin <[email protected]>:
I think 'bitbake -e recipe', and then searching for SRC_URI in it should show which layer applies which patch.
... snip ... I *think* I know what might be happening here, and I'd like to verify some suspicions about how recipes are selected and patches are applied. (Writing this in real time so I hope I don't screw up.) Imagine I've checked out oe-core, which supplies recipe file fubar_1.0.bb, but it becomes obvious that there is a bug, for which there is an obvious patch I can apply internally. So I fire up a fubar bbappend file, which does nothing but extend SRC_URI to apply the patch, call it fubar.patch. (Remember, this patching is all internal, in my vendor layer.) *However*, being a bit lazy, rather than create fubar_1.0.bbappend, I slack off and create simply fubar_1.%.bbappend. (I suspect you see where I'm going with this.) Now the good folks at OE get around to updating oe-core, and part of that update is to add that patch to SRC_URI of fubar_1.1.bb (along with the patch file fubar.patch, of course). Now, because that is a more recent version of fubar, that is the recipe file that should be selected. *However*, if I interpret this correctly, first, I have fubar_1.1.bb applying fubar.patch, but because I am also defining a layer which contains the append file fubar_1.%.bbappend, that append file will also try to apply the same patch, which of course should not work properly. (Am I correct in my thinking so far?) If I'm explaining this correctly, then the fault naturally lies with me for being sloppily ambiguous with my append file and not locking it to fubar_1.0, but allowing it to be applied against all fubar_1.x recipes. In short, when I inevitably get the error of "Patch already applied," it is entirely my fault for being sloppy. I'm trying to verify this as I am now aware that a *lot* of append files in the vendor layer in question are similarly ambiguous. Does this make sense? rday -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
