[meta-ti] Make meta-ti comply with Yocto Project BSP requirements

[Denys Dmytriyenko]

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