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