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

[Maupin, Chase]

> -----Original Message-----
> From: meta-ti-bounces at yoctoproject.org [mailto:meta-ti-
> bounces at yoctoproject.org] On Behalf Of Dmytriyenko, Denys
> Sent: Friday, September 14, 2012 3:08 AM
> To: meta-ti at yoctoproject.org
> Subject: [meta-ti] Make meta-ti comply with Yocto Project BSP
> requirements
> 
> 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.

Denys,

I think having a sub-layer for these recipes would be a good idea.  The pieces in that layer would be the ones that need to find a new home.  So it would act kind of like a buffer layer for pieces in transition rather than having it scattered throughout the meta-ti layer.

> 
> 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
> meta-ti at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti