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

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

[Robert P. J. Day]

  looking for a "best practises" suggestion ... currently working with
a layer based on morty (2.2), migrating it to thud (2.6) and i notice
that there are a *lot* of .bb recipe files in the morty layer that
did not exist in any of the official OE/YP layers in morty, so they
were added by either:

  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)

all of this introduces a bit of complexity.

  when i peruse the recipe (.bb) files in the vendor's morty-based
layer, it's not at all obvious whether a given recipe file was written
from scratch because it did not exist, or whether it was "stolen" from
a newer layer (thud, warrior, etc...) as long as it was compatible.
there is nothing in the log to identify how that recipe file came into
existence, and that makes it messy since it requires examining each
recipe file individually and checking whether there is *now* (or at
least in a newer layer) such a recipe that can be appropriated (and
possibly customized by a simple .bbappend file).

  actual example -- in the vendor's morty-based layer, there is a full
recipe file for "cloc", for counting lines of code. such a recipe did
not exist in any OE/YP layer back in morty ... or thud ... or warrior
... or zeus ... but it was introduced in jan of 2020 in master, ikn
meta-oe/recipes-devtools.

  so, apparently, the vendor wrote a cloc recipe file from scratch as
it simply did not exist anywhere in the OE/YP universe *at that time*.
and something that simple (perl-based program to count lines of code)
is probably going to work fine with any layer.

  so in the midst of migration from morty to thud, that cloc recipe is
*still* not going to exist in thud but, based on my diligent research,
i now know it *will* exist in a newer layer/branch. so what is the
best way to use recipes in that circumstance?

  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?

rday

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

[Adrian Bunk]

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