[OE-core] simplest command to display which layers are applying the same patch?

[Andre McCurdy]

On Thu, Mar 12, 2020 at 7:30 AM <rpjday at crashcourse.ca> wrote:
> Quoting Alexander Kanavin <alex.kanavin at gmail.com>:
>
> > 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.