Systemd is blazing a trail and defining various interfaces to expose OS data to applications which are gradually being adopted by other systems. The systemd maintainers are doing a decent job of documenting the interfaces[1], known consumers and which other systems are supporting them as well as whether they are (easily) re-implementable outside of systemd. It's likely that these interfaces will become de-facto API as other Linux OS's adopt either systemd (increasingly likely) or implement the interfaces themselves and we should consider getting in early and adopting the ones which make sense also. OS's implementing one or more of the API interfaces outside of systemd include: o Arch Linux o Debian o Ubuntu Known consumers of the API interfaces include: o GNOME o udev o X11 Examples of D-Bus API interfaces covered are: o hostnamed[2] o localed[3] o timedated[4] Examples of file API interfaces covered are: o /etc/machine-info[5] o /etc/os-release[6] o /etc/locale.conf[7] Implementing these interfaces will provide: a) better compatibility with Yocto built images which include systemd b) support for upstream software projects which adopt these systemd interfaces c) a modern, leading edge, Linux OS This bug is a tracker bug for myself to consider the interfaces in turn and whether they should be adopted and supported in the Poky distribution configuration. 1. http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart 2. http://www.freedesktop.org/wiki/Software/systemd/hostnamed 3. http://www.freedesktop.org/wiki/Software/systemd/localed 4. http://www.freedesktop.org/wiki/Software/systemd/timedated 5. http://0pointer.de/public/systemd-man/machine-info.html 6. http://0pointer.de/public/systemd-man/os-release.html 7. http://0pointer.de/public/systemd-man/locale.conf.html
The resulting software and configuration files from this bug could likely form a lightweight, portable, embedded-centric implementation of the systemd API and provide a systemd compatible VIRTUAL_RUNTIME-systemd-api or similar.
Those daemons, whilst in the systemd tree, don't actually depend on systemd. I'd be a big fan of packaging them up separately so they can be used without using systemd. (disclosure: I really want hostnamed for guacamayo)
(In reply to comment #2) > Those daemons, whilst in the systemd tree, don't actually depend on systemd. > I'd be a big fan of packaging them up separately so they can be used without > using systemd. That sounds like the right approach to me. What about the file interfaces? Do they get generated by systemd's build system? I'd say we want to think about how those are packaged too.
I suspect that the initial files are assumed to come from "the distribution" somehow.
Since systemd is now integrated in master I guess we can close this one.
master:95b71d2b03a3a6dc5d32a7d6a84ec3420f39aa61 core-image-minimal and core-image-sato could be built with systemd. Test case: https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=549
verified.