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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
