GitLab

The maintainers of dbus, and the maintainers of other D-Bus implementations like dbus-broker, have been vaguely discouraging various of the more complicated forms of <policy> for several years. This is intended to mitigate the fact that the <policy> language is complicated and difficult to get right, and the fact that policy fragments intended to apply to one system service can easily have "action at a distance" on an unrelated system service.

However, this has not been particularly systematic. !76 (merged) added a section §(INTEGRATING SYSTEM SERVICES) to dbus-daemon(1) which encourages the approach taken by accountsservice, fwupd, udisks2 etc.; but if you search dbus-daemon(1) for group, the documentation of <policy group=...> does not indicate that there is anything wrong with that.

We should write down:

• Which forms of <policy> are encouraged (since !76 (merged) this is mostly done, by example, in §(INTEGRATING SYSTEM SERVICES))
• Which forms of <policy> are discouraged
  • Why they are discouraged
• What service authors should do instead (since !76 (merged) this is mostly done, by example, in §(INTEGRATING SYSTEM SERVICES))

For the discouraged forms of <policy>, the documentation that says they exist should also say, in approximately the same place, that they are deprecated.

I think it has become obvious that I am not going to get this done any time soon, so if there are people who feel particularly strongly about particular features being deprecated, please step forward with merge requests.

In the long term, I would like to have a simpler policy language subset in which the deprecated/discouraged constructs are simply not expressible (see #13), but that's out-of-scope for this issue.