Re: [PATCH 00/10] Initial systemd integration

[Ciprian Ciubotariu <cheepeero@gmx.net>]

On Monday 21 January 2013 12:12:14 Burton, Ross wrote:
> On 21 January 2013 03:30, Ciprian Ciubotariu <cheepeero@gmx.net> wrote:
> > However, with oe-core/meta providing a default embedded policy, higher
> > layers need to remove sysvinit or systemd stuff from base recipes, which
> > is
> > against bitbake's additive language design (only append/prepend functions,
> > no -= operator) and against separating concerns.
> 
> If you don't do a systemd build, you won't get any of the systemd
> files.  Ditto, sysvinit (well, that's the goal - as it was an
> assumption until now that needs work still).
> 

Does that mean that I can disable the default init manager somehow, and 
provide my own?

> An oe-core without *any* init system will be very cumbersome - every
> service will need a bbappend to actually work, with the subsequent
> maintenance costs.
> 

I fail to see the overhead of maintaining a feature in one file, and the init-
manager part of the same feature in another file. The actual complexity is the 
same as when adding an use-flag like configuration variable in a single-file 
recipe; perhaps one avoids hitting "Open..." on the editor.

However, if I understand correctly, one can disable the default OE policy for 
an init manager, though not by choice of different layers, but via having 
systemd or not in DISTRO_FEATURES. 

Does this means that 

- having DISTRO_FEATURES += "systemd" we get a system with systemd;
- DISTRO_FEATURES += "sysvinit" makes a system with sysvinit, and 
- leaving DISTRO_FEATURES blank leaves us with a system with no init manager, 
to which we can add our own?

I guess the most important aspect I am trying to communicate is: please do not 
provide any by default.

Cipi

> Ross