Created attachment 89506 [details] [review]
[PATCH] Do not install systemd unit files if build without systemd

The help text for --enable-systemd actually still says

AC_ARG_ENABLE(systemd, AS_HELP_STRING([--enable-systemd],[build with systemd at_console support]),enable_systemd=$enableval,enable_systemd=auto)

which is clearly not the whole story any more... but does make the point that our "systemd support" has several parts.

Our systemd activation support is actually unconditional at compile time (although it can only be enabled at runtime on Unix platforms), and the systemd: transport is only conditional on DBUS_UNIX (although it's just a stub unless __linux__ is also defined). Those are the only bits that the systemd unit actually needs.

--enable-systemd does improve systemd-logind and systemd-journald integration, but it isn't mandatory even on systemd systems, as far as I can see - we use it to support at_console via logind, and to support Journal-based logging, both of which are nice-to-have but clearly optional.

Orthogonally, it's possible to avoid installing the units even if building on a systemd system, via --with-systemdsystemunitdir=no, or equivalently, --without-systemdsystemunitdir.

I can see two routes that make sense:

* Make systemd support monolithic and "all or nothing": use the systemd
  shared library instead of sd-daemon.c, and don't compile anything
  systemd-related unless systemd shared libraries are found.

* Have as much systemd support as possible, even if systemd libraries
  are missing or explicitly disabled.

The former would let us drop sd-daemon.[ch], since at that point we'd be relying on its shared libraries anyway.

The latter gives you a maximally functional "bootstrap" build of dbus (enough to be usable in most production scenarios, even) when using it to break the systemd <-> dbus dependency cycle, on systemd versions that don't yet contain a complete reimplementation of libdbus (which AIUI means every released version, but not the next release?).

Lennart, any opinion on which way we should go?

I'd keep it simple and just turn on everything or turn off everything and that's it.

(In reply to comment #3)
> I'd keep it simple and just turn on everything or turn off everything and
> that's it.

Fair enough. Merged Attachment #89506 [details] for 1.7.10, but I'll leave this open until I've made --[en|dis]able-systemd a bit more all-or-nothing.

Created attachment 91548 [details] [review]
Only support systemd: transport if we have systemd  libraries

This means we can drop our convenience copy of sd-daemon.[ch]. We're
checking for libsd-daemon anyway, to support journald and logind
integration.

(In reply to comment #5)
> Created attachment 91548 [details] [review] [review]
> Only support systemd: transport if we have systemd  libraries
> 
> This means we can drop our convenience copy of sd-daemon.[ch]. We're
> checking for libsd-daemon anyway, to support journald and logind
> integration.

Looks good!

(In reply to comment #6)
> (In reply to comment #5)
> > Only support systemd: transport if we have systemd  libraries
> 
> Looks good!

Thanks. Adding a new dependency for 1.8.0 when I've already done 1.8rc1 seems undesirable, so I'll apply this when I branch for 1.9.

1.9.0