Re: [PATCH 00/10] Initial systemd integration

Ciprian Ciubotariu
2013-01-22T22:20:50Z

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