[Pkg-utopia-maintainers] Bug#712167: dbus: add upstart init support

[Simon McVittie]

On Fri, 14 Jun 2013 at 12:16:28 +0100, Simon McVittie wrote:
> On Thu, 13 Jun 2013 at 19:23:46 +0100, Dmitrijs Ledkovs wrote:
> > The upstart job attached will continue to honour existing
> > settings for additional parameters from /etc/default/dbus, just like
> > the current init.d script.
> 
> Do/should we support that file at all? I can't see anything in dbus-daemon
> --help that you could put there without breaking system integration

Expanding on that a bit: as an upstream D-Bus developer, my policy is
basically "configuration files should be for sysadmins (with sensible
defaults from the system integrator), and command-line options
should be for system integrators":

* if it's configurable and there's any valid reason for a sysadmin to
  configure it, it should be an option in the XML configuration in
  /etc/dbus-1/system.conf, system.conf.local and system.d
  (or session.* for the session bus);

* if dbus-launch or the init script, systemd unit or Upstart job needs
  to force a particular setting in order to work correctly, it should be
  a command-line option instead, and should be hard-coded in the
  appropriate launcher/script/pseudo-executable.

If we stick to that policy, nobody should ever need to set PARAMS in
/etc/default/dbus.

system.conf still contains <fork/> for historical backwards compatibility,
but I don't think that should ever have existed in the XML:
sysadmins cannot usefully reconfigure it, because every script that
launches dbus-daemon either expects it to fork or expects it not to fork,
and is very likely to break if it has the opposite behaviour.

Similarly, if you disable or alter the pidfile in the XML, sysvinit
and Upstart are not going to work correctly. systemd never needs the
pidfile (because it runs dbus-daemon with --nofork, so it's trivial
to know the pid), so it uses --nopidfile for a small performance boost.

    S