@abbradar, thanks for your PR! By analyzing the history of the files in this pull request, we identified @edolstra, @peterhoeg and @wkennington to be potential reviewers.

I think last time we tweaked how dbus reads its config files it became a problem when doing a nixos-rebuild switch from the previous NixOS release to a new release. Might be worth checking it doesn't become a problem again...

It should be okay if done 16.09 -> 17.03 because 16.09 already had and used /etc/dbus-1. BTW current master would break that (it uses /run/current-system/dbus instead).

I've noticed that D-Bus actually reads its own config file from /run/current-system/share/dbus-1/{system,session}.conf first, and then goes to include files from /etc/dbus-1. Because of this we can skip copying this configuration to /etc/dbus-1 and instead just copy {system,session}-local.conf.

cc @layus

@abbradar Yes, I think it is better not to have twice the (nearly) same file. What still bothers me is

1. Relying on the default path of /run/current-system/sw/share/dbus-1/system.conf is crappy. That path is a bundle of all the reachable system packages. You could even have a conflict for that path between two versions of dbus. Who knows what version will win ?
2. relying on the default setting for --system and --session, especially knowing where it comes from, seems a bad idea. From online manuals, I understood that [the] --session option is equivalent to "--config-file=/etc/dbus-1/session.conf" but now I is clear that [the] --session option is equivalent to "--config-file=BDUS_DATADIR/dbus-1/session.conf". Maybe using an explicit path in the service config file would be better than relying on a default that may change in the future.

May I suggest to return to your initial solution, where the service is explicitly started with --config-file=/etc/dbus-1/session.conf ? It feels cleaner to me because 1) anyone reading systemctl cat dbus will know what file is really used by dbus and 2) anyone looking at /etc/dbus-1 will see the files actually used by dbus, as expected (see #20871 (comment))

Also, the default system.conf has <includedir>system.d</includedir>. This relative include means that anything in /run/current-system/sw/share/dbus-1/system.d will be loaded by dbus. I prefer loading /etc/dbus-1/system.d than the above.

A disadvantage of the older approach is that those who do start dbus-daemon by themselves (like Xfce) will anyway go through $out/share/dbus-1/system.conf, which then includes nearly the same file. This also requires hacks like copying and sedding them, and overriding upstream units. For example, they originally also have a call to reload something in dbus which we have removed by our overrides. Feels fishy to me.

We can be sure that dbus will read its own configuration file, and they definitely won't remove inclusion of /etc/dbus-1/*-local.conf files any time soon (feels like a major breakage to me, for example they still include /etc/dbus-1/local.conf even though they mark it as deprecated). I imagine that other distributions/users rely on this file and it's somewhat standartized.

I don't think explicit config file helps users to understand what's going on much because: /etc/dbus-1/*-local.conf are seemingly well-known files and their local suffixes hint clearly that they are our overrides, not complete upstream config; the config itself resides in the package directory, which is a usual situation for NixOS. Finally, closer to the upstream feels better to me -- both in maintenance and in users' expectations (there are more users familiar with upstream than there are with NixOS).

Your concern about system.d and /run/current-system/sw/share in general goes away if we remove our change of datadir to /run/current-system/sw/share -- then D-Bus will read its configuration files from $out which seems the best way to me.

As this creates serious problems for Xfce users (disclosure: myself included but I have a custom nixpkgs branch anyway) I want to merge this sooner and postpone mass-rebuild changes (remove of /run/current-system/sw/share as the data path) for later. However let's wait for a bit -- maybe @layus / others want to express more opinions about both discussed approaches.

Your concern about system.d and /run/current-system/sw/share in general goes away if we remove our change of datadir to /run/current-system/sw/share -- then D-Bus will read its configuration files from $out which seems the best way to me.

Yes, indeed. Lets keep it like this, and try to push the datadir change later.