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 _______________________________________________ meta-ti mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-ti
