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