Man, you are on it! Thanks for the fast response, Gustavo.
The real question here isn't "how to create a layer" or "how to append a recipe" which the documentation explains well, but a higher-level practical question of what is the best way of working with, customizing, and architecting around the existing yocto-based solutions provided by SoC/SoM vendors. It's nice that they provide yocto solutions for free, but IME they sometimes create confusion by fuzzing the lines between "bsp" and "distribution", and not following the Yocto Project's best practices in their documentation and reference platforms, e.g. using the yocto antipattern of modifying local.conf for customizations.
As I mentioned, I'm using the var-som-imx8mp "machine", with varigit/variscite-bsp-platform at mickledore as the "distribution". I was befuddled by their terminology and documentation, and the cognitive dissonance between it and the YP docs, until I forced myself to draw the diagram below, requiring me to dive deep.
variscite-bsp-platform is actually not a BSP. It "has a" BSP, defined in the depths of its `meta-{imx,var}-*-bsp` layers, but it is not a BSP. variscite-bsp-platform is a distribution. Even after understanding this distinction, it is confusing how to move forward with creating one's own distribution layer (per YP best-practices) which "uses" and modifies the variscite-bsp-platform distribution. The canonical "how-to" solution in the variscite documentation is "Add the following line to YOCTO_DIR/BUILD_DIR/conf/local.conf."
On top of these, the tooling used in these vendor BSPs is heterogenous and IMO a bit archaic:, e.g. using git-repo tool manifests instead of standard git submodules (yes, submodules are standard, folks, get used to it), and not standardizing on modern container tooling like kas.
I know the above are not your problem, nor your fault, Gustavo.
..and to suggest and solicit feedback on a canonical solution for future users that like me want to follow YP best practices while using a vendor-provided yocto "distribution" which includes the "bsp" layers for "machine"-specific configuration. The approach is defined by the below list of requirements.
- There is a top-level git super-project that refers to all yocto meta layers and other related software projects. This provides an omniscient single source of truth and logical place for e2e/system-level CI.
- Yocto meta layers are contained in yocto/ subfolder, and are referred to by git submodules.
- Where git-repo tool is used upstream, encapsulate its super-project in a yocto/<repo-tool-layer>/ subdirectory. Note that tooling must be updated to install and invoke the repo tool in all the right places, instead of just `git clone --recurse-submodules`.
- I have automation that will convert git-repo based yocto projects to use git submodules, but have yet to work out the entire workflow.
- Having consistency in this kind of tooling removes much of the barrier to accepting upstream changes, and contributing.
- A new meta-custom-distro layer submodule is created under yocto which defines a new distro named custom-distro in the standard conf/distro/custom-distro.conf file.
- The distro conf also provides the variable modifications required to implement the desired changes, e.g. tweaking DISTRO_FEATURES or *IMAGE_INSTALL vars to include or exclude features or packages. Notably, this is the YP best-practice way of customizing a distribution, as opposed to modifying local.conf, or worse, modifying the upstream sources in place without forking.
- recipes may be added here to refine changes made to variables above, and to add new features, configuration, or packages that are truly specific to the purpose of custom-distro.
That's it. Everything else is not distro-specific, i.e. you can add other meta layers to the project as normal, to add new recipes or append existing ones.
I'd love to hear your feedback on this approach, @gusarambula or anyone. It all seems pretty standard to me. It was just helpful for me to write this all out explicitly since it goes against the grain of my "bsp platform" vendor's documentation. Thanks for reading my brain dump.
