$(sysconfdir)/dbus-1/system.d vs $(datadir)/dbus-1/system.d

[Simon McVittie]

On Tue, 19 Mar 2019 at 16:43:23 +0000, Дилян Палаузов wrote:
> If $(datadir)/dbus-1/system.d/A.conf and
> $(sysconfdir)/dbus-1/system.d/A.conf both exist, does by the default the
> sysconfdir location take precedence?

Sort of. The XML configuration language is parsed in order, and the
directives found in each file are collected into a list. It isn't
like systemd, where creating /etc/tmpfiles.d/foo.conf results in
/usr/lib/tmpfiles.d/foo.conf being ignored completely.

I personally think systemd's design for this sort of thing is better, but
changing dbus to behave more like systemd would be an incompatible change.
We're constrained by the fact that the XML configuration language works
in terms of files that "include" each other and behave as though the
included text appeared inline in the original file, not files that
override each other.

> Is /usr/local/share/dbus-1/system.d/ by default ignored, if Dbus has
> the configuration file above?

Yes. See also <https://gitlab.freedesktop.org/dbus/dbus/issues/253>.

Getting policy snippets from /usr/local/share/dbus-1/system.d to be
parsed with the correct precedence is not as easy as you might think
(again, see that bug).

> Or with other words, is
>   echo `pkg-config --variable datadir dbus-1`/dbus-1/system.d/
> 
> the only right place where a package shall install its policies,
> irrespective of the $(prefix) for the package?

Installing files outside your ${prefix} will make you unpopular. I would
recommend installing files into your ${datadir}/dbus-1/system.d (your
app's datadir, not dbus' datadir) and documenting that they might need
to be copied or symlinked into the system-wide location.

(This is the same as for systemd system services, but confusingly, not
the same as D-Bus system .service files, for which
/usr/local/share/dbus-1/system-service is explicitly in the search path.)

If your $(prefix) is not /usr/local (/opt/gnome or something), then
sysadmins who install your software will always need to take special steps
to get your integration files to be read by the system *anyway*; this is
the same as for any other integration files (for instance desktop apps
in /usr/share/applications and pkg-config metadata in /usr/lib/pkgconfig).
/usr/local sometimes gets a special case and sometimes doesn't.

    smcv