NOTES.md

NOTES

• The layers are non-yocto-compliant in a number of ways: parsing issues, signature changes, etc
• A number of yocto conventions are violated with varying consequences. For example, machine specifics in layer.conf.
• Cross-layer dependencies without state LAYERDEPENDS, i.e. meta-bsp on meta-sdk, though only for certain recipes.
• Exceeding the purpose of the individual layers, both relating to yocto compliance and not. BSPs should not make changes that aren’t specific to that which is needed for the machine, and should avoid altering core components, such as busybox.

As a quick summary of the meaning of Yocto Project Compatible, "Yocto Project Compatible status is appropriate for products, BSPs and other OE-compatible layers, and related open-source projects. These components must be maintained and submitted by an open source project, non-profit, or Yocto Project member organization."

Regarding Yocto compatible/compliant, the ones I see as being an issue for meta-imx follow:

• 5. All publicly accessible layers are listed in the OpenEmbedded Layers index (http://layers.openembedded.org).
• 9. All layers contain a README file which details the origin of the layer, its maintainer, where to submit changes, and any dependencies or version requirements.
• 10. All layers build without errors against OpenEmbedded-Core, with only the dependencies/requirements listed in their README file?
• 11. All layers have successfully passed the test script yocto-compat-layer.py.
• 13. Hardware support, configuration (distro) policy, and recipe metadata are separated into different layers which do not depend on each other.

While these do not explicitly state the requirement that layers do not alter metadata unless opting in to such changes, it does require yocto-check-layers (the name changed from yocto-compat-layer.py) be run, which explicitly tests for this. A DISTRO layer should not change the build unless the DISTRO is set to one of the distros provided, that a BSP layer not change the build unless the MACHINE is set to a MACHINE provided, and while not directly required, ideally that software layers avoid changing the build unless explictly opted into (for example, meta-virtualization requires a distro feature to enable much of its functionality, and some other feature layers work similarly, either requiring a feature be set, or that a particular config file be included).

meta-bsp also lacks a README and isn't listed in the layer index. Admittedly, you're welcome to avoid submitting these layers for Yocto Compatible status, but this status explicitly identifies items which are Yocto conventions, so I believe it's worthwhile. Of course, it's your call to make.

The concepts of certain core axes around which the build orients was one of the main concepts defined when creating the design of OpenEmbedded when the project was started, along with physical layering (layers/collections) and metadata layering (overrides). The distro, machine, image axes are central, but some of the other conventions are along similar lines. For example, a distro layer that enables functionality without setting DISTRO will limit project flexibility, in that the layer cannot be included otherwise without impacting things you'd normally want to avoid impacting. In the case of distro, it's less common, but still a viable use case, as one may want specific config files, classes, or recipes from such a layer, without the rest. Similar logic applies to others. Maximizing flexibility while retaining certain separations by convention is key to the project. From an old writeup I did on the distro/machine/image, "It's important to remember that distro, machine, and image are always intended to be orthogonal, and this guides a great deal of what we do. We want any combination of the 3 to work, within reason. So, if a given package is required to boot a board, then it needs to be pulled in via the machine, otherwise use of a different distro would result in non-booting images. If a given package isn't required to boot the board, then it belongs in the hands of the distro or the image, and needs to be considered on a case-by-case basis.".

The changes in layer.conf that are unusual are placed there to enable overriding of specific machine-specifics from the machines defined in meta-freescale, only when meta-imx/meta-bsp is included. I can see the reasoning, they presumably wanted to avoid having to define new machines for them all, but wanted to build upon the community machines, but placing it here is far from ideal, and results in changing behavior solely based on layer inclusion, which deviates from Yocto conventions. While Yocto has a great deal of flexibility regarding what metadata goes where, there are certain core philosophies to the design and areas of responsibility, as mentioned previously.

There are certainly exceptions to these guidelines. In the case of meta-imx/meta-bsp, I can see the argument that it be allowed to alter metadata on layer inclusion, as it's not truly an isolated BSP/MACHINE layer, it builds upon and modifies another such layer, but it does mean it's not possible to opt out of the meta-bsp changes without a fair amount of duplication of metadata.

I would strongly suggest considering alternatives which are more in line with Yocto conventions:

• Create your own MACHINE definitions which build upon the meta-freescale definitions, including and setting MACHINEOVERRIDES as appropriate to ensure correct sharing of metadata. This brings the layer more in line of a typical BSP/MACHINE layer, as you opt in by setting MACHINE appropriately. Presumably this would impact your documentation and setup scripts, of course.
• Add a config file which may be included from local.conf to opt-into the modifications to the meta-freescale machines. As you control your setup scripts for your vendor setups, this would be viable, and this requirement could be documented in the README.

Given the required scope of the changes, I think this would be appropriate. Of course, an alternative would be to bbappend every recipe affected by these variable changes and make them conditional upon a machine feature instead, but that's uglier and harder to maintain than the previous suggestions.