All, One of the requirements for a BSP layer to be officially Yocto Project compliant or compatible is to avoid mixing hardware suport with policy configuration. Here is the corresponding commit from Richard to split meta-yocto into distro and BSP pieces, as separate layers:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/commit/?id=eac90e27a032ea23d9a4f35c7eef8b1940c80e22 In meta-ti we have several levels of severity in violation of this requirement: 1. Depending (i.e. DEPENDS/RDEPENDS) on packages from another "application" layer, such as meta-oe, meta-systemd, etc. It can be argued that such dependency is not on "policy configuration", plus it does not break parsing, unless problematic recipes need to be built, thus mark it as lower priority for now. 2. Depending (again, DEPENDS/RDEPENDS) on packages from a "distribution" layer, such as meta-angstrom (or potentially, meta-yocto or meta-arago). This does not break parsing, but violates the above requirement, by depending on a specific "policy configuration" layer. Medium priority. 3. Inheriting (i.e. inherit systemd) classes from another layer, such as meta-systemd. This behavior breaks parsing and requires BBMASK-ing those problematic recipes. Although, it requires an "application" layer and not a "distribution" one, it's quite bad nonetheless, as it breaks parsing. High priority. 4. Including (i.e. require/include) a file from a "distro" layer - again, depending on a specific "policy configurtion" layer is in violation of the requirement. And using "require" will even break parsing, when such layer is not referenced in the BBLAYERS stack. There are also problems with "include" as well, when variables like LICENSE are expected to be set by distro layer. High priority. I'd like to start addressing these issues in the reverse order, according to the priority. There is a RFC with 2 possible quick/temporary workarounds to "fix" #4. Please provide feedback for those. The longer-term proper solution would be to split out offending recipes into a separate layer. Nobody wants to simply remove them - we want to preserve them, just put them in right place. I can create a sub-layer inside meta-ti and move the recipes there - can send a patch/proposal right away. Or we can agree to host them in an outside layer - once they are copied there, I can remove them from meta-ti. Let's agree on something. Yes, the topic of moving those recipes into a separate layer was discussed here ad nauseam lately, but this email is meant to lay down the official reasons for such move and follow through. Thank you for your cooperation. -- Denys _______________________________________________ meta-ti mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-ti
