Re: best practises: how to properly "steal" recipes from a newer layer?

[Adrian Bunk <bunk@stusta.de>]

On Sun, Mar 01, 2020 at 03:29:35PM -0500, Robert P. J. Day wrote:
>...
>   1) writing the recipe from scratch, compatible with morty, or
>   2) flat-out stealing that recipe from a *newer* layer, as long as
>      it was compatible (this was done frequently)
>...
>   if i just blindly copy the recipe file forward, i'm going to have to
> go through this all again at the next migration. is there a reasonable
> way to add recipes to my (thud-based) layer that clearly shows those
> recipes are being scarfed from a newer layer? and i don't mean
> mentioning that in the commit msg as that will still require perusing
> all those commit messages.
> 
>   is there a clean way to do this? it may sound trivial, but in this
> case, i'm looking at a couple hundred recipes that eventually show up
> in newer layers that i could steal, and i really want to hang onto
> that information for the next migration.
> 
>   thoughts?

My usual approach for 2) is to have a recipes-backport/ in the layer 
that contains all recipes taken from more recent layers - completely
new recipes, new versions of recipes, and sometimes just one specific
change backported into a .bbappend.

Example in a layer for warrior (dropping an unwanted patch):
$ cat recipes-backport/e2fsprogs/e2fsprogs_1.44.5.bbappend 
SRC_URI_remove = "file://Revert-mke2fs-enable-the-metadata_csum-and-64bit-fea.patch"
$

If you have many backported changes and migrations are often not to the
latest Yocto release, you could further split this into 
recipes-backport-from-warrior/ etc.

With an "upstream first" policy all upstreamable cases of 1) become
cases of 2). For the example above see [1].

> rday

cu
Adrian

[1] https://github.com/openembedded/openembedded-core/commit/f5edce401cfb31ebd0200adaba9a201caf7ea705