Make meta-ti comply with Yocto Project BSP requirements

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

Re: Make meta-ti comply with Yocto Project BSP requirements

[Tomas Frydrych]

On 14/09/12 09:08, Denys Dmytriyenko wrote:
> 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.

I am not sure about this one; it is reasonable / necessary for a bsp
layer to provide an -initd / -systemd packages (e.g., the pvr drivers
need this, the gstreamer-ti package needs this), and as long as there is
no systemd.bbclass in oe-core, I suspect the only answer is to split the
bsp layer into -bsp, -bsp-initd and --bsp-systemd. I am not sure whether
such endless proliferation of layers is a particularly good solution?

Tomas

Re: Make meta-ti comply with Yocto Project BSP requirements

[Richard Purdie]

On Fri, 2012-09-14 at 11:26 +0100, Tomas Frydrych wrote:
> On 14/09/12 09:08, Denys Dmytriyenko wrote:
> > 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.
> 
> I am not sure about this one; it is reasonable / necessary for a bsp
> layer to provide an -initd / -systemd packages (e.g., the pvr drivers
> need this, the gstreamer-ti package needs this), and as long as there is
> no systemd.bbclass in oe-core, I suspect the only answer is to split the
> bsp layer into -bsp, -bsp-initd and --bsp-systemd. I am not sure whether
> such endless proliferation of layers is a particularly good solution?

I don't think PVR modules having a dependency on some particular init
system is a good thing.

What we need is a good core init system architecture and then these
pieces can plug into that in whatever way is appropriate.

I appreciate we're not there yet however I think the overall goal of
separating hardware support from "policy" is a good one. There are a few
pain points we need to work through but if it was easy, we'd already
have done it :)

systemd support in OE-Core is being deferred to 1.4 as I want it done
well and would be too rushed given where we're at in the schedule now.

Cheers,

Richard

Re: Make meta-ti comply with Yocto Project BSP requirements

[Gary Thomas]

On 2012-09-14 05:29, Richard Purdie wrote:
> On Fri, 2012-09-14 at 11:26 +0100, Tomas Frydrych wrote:
>> On 14/09/12 09:08, Denys Dmytriyenko wrote:
>>> 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.
>>
>> I am not sure about this one; it is reasonable / necessary for a bsp
>> layer to provide an -initd / -systemd packages (e.g., the pvr drivers
>> need this, the gstreamer-ti package needs this), and as long as there is
>> no systemd.bbclass in oe-core, I suspect the only answer is to split the
>> bsp layer into -bsp, -bsp-initd and --bsp-systemd. I am not sure whether
>> such endless proliferation of layers is a particularly good solution?
>
> I don't think PVR modules having a dependency on some particular init
> system is a good thing.
>
> What we need is a good core init system architecture and then these
> pieces can plug into that in whatever way is appropriate.
>
> I appreciate we're not there yet however I think the overall goal of
> separating hardware support from "policy" is a good one. There are a few
> pain points we need to work through but if it was easy, we'd already
> have done it :)
>
> systemd support in OE-Core is being deferred to 1.4 as I want it done
> well and would be too rushed given where we're at in the schedule now.

When that does happen, I hope that it will still be possible to have
a distribution which uses initd.  Will that be the case, or do we all
have to follow down the systemd yellow brick road (which I personally
am not in favour of)?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Make meta-ti comply with Yocto Project BSP requirements

[Richard Purdie]

On Fri, 2012-09-14 at 05:45 -0600, Gary Thomas wrote:
> On 2012-09-14 05:29, Richard Purdie wrote:
> > On Fri, 2012-09-14 at 11:26 +0100, Tomas Frydrych wrote:
> >> On 14/09/12 09:08, Denys Dmytriyenko wrote:
> >>> 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.
> >>
> >> I am not sure about this one; it is reasonable / necessary for a bsp
> >> layer to provide an -initd / -systemd packages (e.g., the pvr drivers
> >> need this, the gstreamer-ti package needs this), and as long as there is
> >> no systemd.bbclass in oe-core, I suspect the only answer is to split the
> >> bsp layer into -bsp, -bsp-initd and --bsp-systemd. I am not sure whether
> >> such endless proliferation of layers is a particularly good solution?
> >
> > I don't think PVR modules having a dependency on some particular init
> > system is a good thing.
> >
> > What we need is a good core init system architecture and then these
> > pieces can plug into that in whatever way is appropriate.
> >
> > I appreciate we're not there yet however I think the overall goal of
> > separating hardware support from "policy" is a good one. There are a few
> > pain points we need to work through but if it was easy, we'd already
> > have done it :)
> >
> > systemd support in OE-Core is being deferred to 1.4 as I want it done
> > well and would be too rushed given where we're at in the schedule now.
> 
> When that does happen, I hope that it will still be possible to have
> a distribution which uses initd.  Will that be the case, or do we all
> have to follow down the systemd yellow brick road (which I personally
> am not in favour of)?

I want to systemd being optional with people electing to use or not use
it...

Cheers,

Richard

Re: Make meta-ti comply with Yocto Project BSP requirements

[Tomas Frydrych]

On 14/09/12 12:29, Richard Purdie wrote:
> On Fri, 2012-09-14 at 11:26 +0100, Tomas Frydrych wrote:
>> On 14/09/12 09:08, Denys Dmytriyenko wrote:
>>> 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.
>>
>> I am not sure about this one; it is reasonable / necessary for a bsp
>> layer to provide an -initd / -systemd packages (e.g., the pvr drivers
>> need this, the gstreamer-ti package needs this), and as long as there is
>> no systemd.bbclass in oe-core, I suspect the only answer is to split the
>> bsp layer into -bsp, -bsp-initd and --bsp-systemd. I am not sure whether
>> such endless proliferation of layers is a particularly good solution?
> 
> I don't think PVR modules having a dependency on some particular init
> system is a good thing.
> 
> What we need is a good core init system architecture and then these
> pieces can plug into that in whatever way is appropriate.

You could have a single bbclass that would provide the necessary
functionality for both systems; the current two classes could just be
aliases for it, providing backward compatibility. That would make the
basic problem of having more than one init bbclass go away.

> 
> I appreciate we're not there yet however I think the overall goal of
> separating hardware support from "policy" is a good one. 

Yes, but we are not talking about having policy in the bsp layer, we are
talking about the bsp layer supporting common policy types that a higher
layer can choose to impose. I think the distinction between 'policy' and
'policy awareness' is an important one.

> There are a few
> pain points we need to work through but if it was easy, we'd already
> have done it :)
> 
> systemd support in OE-Core is being deferred to 1.4 as I want it done
> well and would be too rushed given where we're at in the schedule now.

Actually, there is a really simple fix for this specific problem, and
that's for oe-core to include a dummy systemd.bbclass that does nothing.
This stops the parsing from being broken, and it makes no difference if
you are including meta-systemd.

Tomas

Re: Make meta-ti comply with Yocto Project BSP requirements

[Maupin, Chase]

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