On Thu, Feb 21, 2013 at 12:35 PM, Burton, Ross <[email protected]> wrote: > 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".
Awesome. I agree it is difficult to track in a such big thread. > "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. Right. However BAD_RECOMMENDS is a little *manual* ... more on this later ... > When people are building images with and without systemd, how are the > non-systemd images booting? If sysvinit, what's the rationale for Last time I tested no. systemd-udevd would need to be split from systemd package and have init scripts as an option. > 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. No; one of our products is build with an initramfs (using initramfs-framework) and it is much easier for this than the systemd. In some cases we use the init.d scripts provided by packages to allow reuse in initramfs-framework and it works fine. > 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). Yes; this is a regression from the status we had in meta-oe *before* the merge in oe-core. It was more flexible. > 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. Yes; this is one problem. I think we might think about havig something in package manager that try to fullfil a virtual provide (as we had for locales). > 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. It depends. If I have 'systemd' enabled in the distro I am sure expecting it to happen. If I don't, I don't expect it to happen. -- Otavio Salvador O.S. Systems E-mail: [email protected] http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
