Re: [PATCH 00/10] Initial systemd integration

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2013-01-23 at 00:04 +0200, Ciprian Ciubotariu wrote:
> 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?

Its always been possible to provide your own init manager. The initramfs
filesystems do this, as does poky-tiny, you simply provide your own init
system dependencies and pull them in instead of sysvinit or systemd.

On more complex images, init systems are a little more complex than that
though.

> > 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?

Those flags control the way some recipes build. Those recipes have
source code which does different things depending on whether sysvinit or
systemd is configured. This is not our code, its upstream. You can
control the way any package builds using the usual overrides mechanism.
The system is about as configurable and customisable as you can get.

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

By default users expect the system to boot and to work. They don't
expect to have to add in layers just to get the system to initialise. We
need to support a sensible core offering of init features. We support
minimal configurations like tiny and the initramfs scripts, we now also
support a choice between systemd and clasic sysvinit. This doesn't mean
you have to use them, you're free to override and configure the system
as you wish, as you have always been able to do.

The request for no default simply does not make any sense. The fact we
have a default doesn't stop you adding your own (as the meta-systemd
layer has demonstrated).

Cheers,

Richard