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 _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
