[systemd-devel] [PATCH 1/2] tmpfiles.d: split files to cope with split packages.

Gustavo Sverzut Barbieri gustavo.barbieri at intel.com
Tue Sep 30 10:36:07 PDT 2014


On Tue, Sep 30, 2014 at 04:26:38AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Sep 25, 2014 at 06:12:50PM -0300, Gustavo Sverzut Barbieri wrote:
> > etc.conf was selectively (using m4) using resolved link, now this is
> > moved to systemd-resolved.conf file. The etc.conf can be static and
> > does not need to be generated anymore.
> >
> > systemd.conf was doing all the journal setup, now this is moved to
> > systemd-journald.conf file.
> Is this useful? We don't support journald-less setups.

I did forget about this part but it is important, so here it is:

I just tested, although journald-less systems are not supported,
they work beautifully (as beautify as it can).

and we run great without a dbus-daemon, even if not running kdbus as
systemctl bus is private and we can do with that (I didn't even think
about that, someone at #systemd alerted me and it will help to stop
those people that complain about dbus usage and that we could "just do
socket", the private socket is basically the same, but the protocol is
a standard and not just some random handcrafted one).

my goal is to provide a decent systemd package for yocto, it will be
split so people can choose what to use, but there are a "-essential"
package that includes sysusers, sysctl, tmpfiles, journald... as well
as a "-base" that includes hostnamed, localed, timedatad... and a
"-all"  with all packages that would not be so common in embedded
systems such as machined, nspawn...

right now I see embedded systems people doing the mistake of running
away from systemd with many wrong reasons. One of them is size, but
they do compare busybox + sysvinit and that includes nothing. When we
compare just systemd to busybox+sysvinit we realize they are not that
far away and that reason goes away. Since almost no system will work
solely on busybox + syvinit, then people will add stuff on top, and
while systemd would pay off, people already made the previous choice
to NOT use it... making the mistake even bigger.

my hope is to deliver the split packages to the yocto project and some
comparison of size and features. even with the bare systemd, no
journal or similar, you already get much more, from cgroup management
(and proc babysitting) to sandboxing (useful in embedded and in many
forms using systemd, from seccomp to selinux), private network,
private tmp, etc. You also get timer so no need for cron/at, you get
proper dependencies and much more as you know.

it will also highlight what you get when you add the different
needs. Take runtime package management (rpm/opkg), if there is a
package that adds users/groups for its services, traditionally you
pull in shadow* packages, which is way bigger than sysusers!

--
Gustavo Sverzut Barbieri
Intel Open source Technology Center


More information about the systemd-devel mailing list