dbus: Removing unmaintained distro-specific init scripts
smcv at collabora.com
Thu Jul 6 11:21:33 UTC 2017
[Slackware developers: please pass this on to whoever maintains the
dbus package in your distribution, I couldn't find a specific maintainer
dbus is the reference implementation of D-Bus, and in particular contains
the reference dbus-daemon. Among other things, this is used to run the
/system bus/, a system service, on Unix platforms.
At the moment, upstream dbus contains the following ways to start the
* A distribution-neutral systemd unit, used in anything that boots with
systemd (Fedora, Ubuntu, default Debian installations etc.). This is
actively maintained, and I'm not going to remove it.
* An LSB-style init script for Red Hat and related distributions
(bus/messagebus.in). This was used in Red Hat and Fedora before they
adopted systemd, but as far as I know is not used any more.
I am concerned that this is unmaintained.
* An LSB-style init script for Slackware (bus/rc.messagebus.in),
which appears to be very bare-bones and in particular has an inadvisable
use of killall. This does not appear to be used in Slackware, which
ships a different (patched?) implementation of rc.messagebus .
I am concerned that this is unmaintained.
* Something analogous to an init script for Cygwin (bus/messagebus-config.in)
I am concerned that this is potentially unmaintained.
None of the init scripts have changed since 2010, and it isn't clear to me
whether they are maintained or actively used. Linux distributions that boot
with sysvinit (older or non-default Debian installations, Devuan, etc.)
typically provide their own LSB init script instead of using the ones
we provide upstream (for example  in Debian/Devuan), which means the
ones we provide upstream are not tested and therefore probably don't
actually work. I would like to remove anything that is not actively
supported by contributions to the upstream project, to avoid giving a
false impression of quality or support.
I propose that in the dbus 1.11.x development branch leading to
the dbus-1.12 stable release, we remove the Red Hat init script, the
Slackware init script, and the Cygwin "config". Launching dbus-daemon
from third-party init scripts using its documented command-line options
will continue to be a valid configuration (to be completely clear,
I am **not** proposing to make systemd the only supported platform),
but downstreams that use an integration layer other than via systemd
to start the system dbus-daemon will be responsible for maintaining
that integration layer themselves. In practice, it appears that they
This would have the following effects on third-party distributors:
* Linux distributions that exclusively boot with systemd would be
unaffected, because upstream contributors (including me) actively
maintain this configuration
* OS distributions that (exclusively or optionally) boot with LSB
init scripts, Upstart jobs or other integration that they add downstream
(Slackware, Debian, Devuan) would be mostly unaffected
- However, if they use the --with-init-scripts=redhat configure argument
for its side-effect of changing the pid file location, or if they
rely on Red Hat being auto-detected, they will have to pass the
--with-system-pid-file=PATH configure argument instead
* OS distributions that rely on --with-init-scripts=redhat,
--with-init-scripts=slackware, --with-init-scripts=cygwin, or
auto-detection of Red Hat, Slackware or Cygwin will need to take
action to provide their own init scripts
As an alternative, I don't mind keeping bus/messagebus.in (historically
Red Hat), bus/rc.messagebus.in (Slackware) and/or bus/messagebus-config.in
(Cygwin) in the upstream dbus project, **if** some named person or group
is willing to commit to providing timely testing and patches to ensure
that they continue to be correct in the upstream development branch
However, I suspect that in practice downstreams will find it easier
to maintain their init-scripts "out of tree", like I do for the LSB
init script provided by Debian. This has the advantage that the
downstream distributor can make full use of any vendor-specific tools,
like Debian's start-stop-daemon, to make their init script better.
If you are an affected downstream distributor, please respond to
dbus at lists.freedesktop.org or to the issue report that tracks this
proposed change, <https://bugs.freedesktop.org/show_bug.cgi?id=101706>,
with any comments or questions that you have.
This message should also serve as a reminder that if you have
vendor-specific patches to dbus, patches that are contributed via
https://bugs.freedesktop.org/enter_bug.cgi?product=dbus will be
considered for inclusion and reviewed for correctness, but patches that
are merely present in your downstream source distribution will likely
never be reviewed or merged by the upstream maintainers. Even if you don't
think a patch is going to be accepted upstream, it might be worthwhile
to attach it to a feature request so that the dbus maintainers can review
it and point out any non-obvious issues.
More information about the dbus