> -----Original Message----- > From: [email protected] [mailto:meta-ti- > [email protected]] On Behalf Of Dmytriyenko, Denys > Sent: Friday, September 14, 2012 3:08 AM > To: [email protected] > 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 > [email protected] > https://lists.yoctoproject.org/listinfo/meta-ti _______________________________________________ meta-ti mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-ti
