How to update GSettings from DBus without X display ?

[Simon McVittie]

On Thu, 23 Mar 2017 at 20:50:52 +0100, Cyril Brulebois wrote:
> I haven't toyed with those yet, but I think they should do the job for
> Hypra's needs. Alex, this is likely the same kind of tools as those I've
> mentioned earlier (Xvfb to create an X11 display, and xvfb-run to run a
> specific application within such a display); except they're specifically
> dealing with D-Bus, which should give us what we need.

If you are looking at things like xvfb-run, then you want dbus-run-session
to accompany it.

However...

> > I suspect that the real problem here is that you are trying to do
> 
> The context is a derivative distribution where most things revolve around
> the first user, with automatically tweaked/upgraded configuration. It's
> been historically done by tweaking user data from maintainer scripts,
> which while not Debian Policy compliant, has proven to just work, and
> is probably not easy to migrate away from.

If you are going to edit this first user's configuration from a
maintainer script, you need to be aware that the main thing dconf
uses D-Bus for is as a mutex. If you use dbus-run-session to do
dconf things in a short-lived session, while another dconf is running
in the actual graphical session, and they are both trying to write
to the same ~/.config/dconf, then they *will* conflict, and it
is not defined which one will win (and get its writes onto disk).
dconf is not designed to cope gracefully with this situation. I think
it at least uses the atomic-overwrite trick, so you get one version
or the other, but it's undefined which one.

If you are using systemd-logind and you have dbus-user-session installed,
it is possible to use an existing or new session bus by acting like a
second parallel login session (and in particular opening a logind session
like libpam-systemd does). As far as I'm aware,
https://lists.freedesktop.org/archives/systemd-devel/2015-January/027711.html
is the best reference on how this works. This would mean you get to
cooperate with the existing dconf instance.

As a longer term solution I would recommend using GSettings *vendor
overrides*, which are intended for precisely this sort of thing.
For instance, on a Debian GNOME desktop, take a look at how
/usr/share/glib-2.0/schemas/10_gnome-shell.gschema.override
overrides some default values from
/usr/share/glib-2.0/schemas/org.gnome.shell.gschema.xml.
User configuration (if the user has changed a setting away from the
default, but not if the user has left it untouched) overrides both.

I think there are also two flavours of sysadmin configuration in /etc, one
of which has an intermediate priority between /usr/share and ~/.config
(back in the days of gconf this was called *defaults*), and the other of
which is even more "important" than ~/.config and can be used as a lockdown
mechanism on kiosk computers etc. (in gconf this was called *mandatory*).
I don't know the finer details of those - please talk to dconf and/or
GSettings developers, or read GNOME sysadmin documentation, for more on that.

Hope this helps,
    S