[OE-core] RFE: make the init manager an image feature (again)

[Burton, Ross]

Hi,

This thread started sprawling, so I'll do my best to cover all the
points.  This is also mainly an attempt to get more information as to
how people are using init managers, as it's still not very clear what
people want beyond "choice".

"With recent systemd packaging change, the rescue image size grow up
from 5.9 MiB to 27 MiB because systemd dependencies are hardcoded in
mandatory packages."

This certainly can happen.  core-image-minimal-initramfs went from 19M
up to 35M if you turn on systemd with the (unmerged) busybox enabling
turned on.  Investigating this shows that the cause was busybox
recommending busybox-syslog which depends on systemd, which isn't
useful in the initramfs.  My branch adds busybox-syslog to
BAD_RECOMMENDS and it's back down to 19M.  This works as this image
has a custom /sbin/init so it doesn't use an init manager at all.

When people are building images with and without systemd, how are the
non-systemd images booting?  If sysvinit, what's the rationale for
this?  Will you consider switching to systemd for everything if the
disk increase was only a new MB, on the grounds of consistent booting
behaviour?  I can imagine many rescue or initramfs images are using a
custom /init, but as these don't/shouldn't actually have any daemons
installed this is practically a solved problem.

systemd as integrated is currently too big for very constrained
environments, and I'm not denying that.  Using this
core-image-minimal-initramfs as a test whilst pulling in systemd I've
been cleaning up spurious dependencies and have managed to trim around
4MB from the footprint, but there's massive low-hanging fruit like a
4MB /lib/udev/hwdb.d.  Rescue images likely don't need this, so we can
split it out and not always install it (now down to a 5MB footprint
compared to no init system).

One massive problem with making init system an image time choice with
packages is what happens when you have a feed with both pn-sysv and
pn-systemd packages in.  If after the initial construction you want to
install a daemon, you'll have to know to manually install the right
init package too.

Supporting multiple init systems in the same packaging would be
achievable, but would people who want this be happy with pulling the
systemd libraries into sysvinit images?  The alternative is that if
sysvinit and systemd are enabled we can't do any real systemd
enabling.   The good thing is that we could certainly make
systemd.bbclass inject a recommends instead of dependency on systemd
and add guards around the systemd calls, ditto for update-rcd.bbclass.

Regards,
Ross