On Thu, Mar 12, 2020 at 7:30 AM <[email protected]> wrote: > 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.
Not really. Upstream oe-core could equally well have added the patch to fubar_1.0.bb, so using a version specific .bbappend doesn't give any guarantees that you don't try to apply the same patch twice. > 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? There are two approaches to applying fixes to upstream layers such as oe-core. One is to create a separate layer containing .bbappend files, the other is to maintain your own fork of the upstream repo. Both approaches work but maintaining your own fork has a number of advantages: - Any changes you make are easier to submit upstream (since you are always creating patches against the upstream repo) - You can directly cherry pick upstream fixes or version updates for specific recipes you care about - If necessary, you can easily revert upstream changes - If you rebase to a new upstream release, there's a good chance that cherrypicked upstream backports magically disappear with no effort on your part - If you rebase to an new upstream release, you get a clear warning (merge conflict) if a change you've made conflicts with a change upstream - Some changes are much more difficult to make via .bbappends but easy to make directly in the original meta layer (e.g. try adding a patch to gcc) Maintaining your own fork of an upstream meta layer may not be for everyone, but for the situations you've been describing recently (ie where you have a large number of .bbappends for oe-core which you want to migrate to a new OE release) it may be the better approach. -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
