nixos/dconf: Allow creating custom databases

[jtojnar]

GLib’s GSettings system stores application settings in one of supported backends and uses compiled schemas (located in $XDG_DATA_DIRS/glib-2.0/schemas/gschemas.compiled) to determine type and default value of configuration keys. The schemas are compiled from XML files provided by applications and optionally, the default value can be changed by overrides.

Current situation

At the moment, we use GSettings overrides to declaratively change settings for GNOME & co., relying on the overridden default value. While this is great for non-important things like distribution-default background image, it suffers from many problems and inconveniences:

• Since the compiled schemas are looked up in XDG_DATA_DIRS on first come, first served basis, we need to make sure our overrides are first in the chain. This is only possible by patching GLib.
• Passing the NIX_GSETTINGS_OVERRIDES_DIR environment variable to applications is fragile. It does not really work for things like display managers, resulting in issues like GNOME keeps suspending on unstable #42053
• It is easy to change a setting key in the user interface, breaking the overrides.
• Compiling overridden schemas requires packages with matching XML definitions.
• extraGSettingsOverrides option needs to be written in keyfile syntax, it would be much more convenient if we could use Nix syntax.

The goal of this issue is to attack the problem from the other side: modifying the backend.

Going through the backend

On Linux, the dconf backend is commonly used. It will select a profile pointing to a list of binary databases that are used for retrieving settings, see its overview for the gory details. Since the database is binary, the attrsets serialized into keyfiles will need to be compiled with dconf compile

Our dconf module can create profiles, which GDM module is incorrectly taking advantage of. In order to be able to configure application declaratively, we would also need to generate keyfiles and compile them to databases.

We probably do not want people to have to spell everything out

programs.dconf.profiles.user = pkgs.writeText "dconf-user-profile" ''
  user-db:user
  system-db:nixos
'';
programs.dconf.systemDatabases.nixos.system.proxy.http.host = "172.16.0.1";

It is not clear to me how should we handle locking – do we allow users to change the keys set through the module? Do we add lock control in the module?

Interesting links

• https://wiki.gnome.org/Projects/dconf/SystemAdministrators
• https://github.com/rycee/home-manager/blob/master/modules/misc/dconf.nix
• GNOME keeps suspending on unstable #42053 (comment)

cc @worldofpeace @hedning

[worldofpeace]

It is not clear to me how should we handle locking – do we allow users to change the keys set through the module? Do we add lock control in the module?

I'd think if someone declared a key in the module that they'd want it to not change.

Though reading https://wiki.gnome.org/Projects/dconf/SystemAdministrators

Presently (as of dconf 0.7.4) lockdown is only supported on a per-key basis. Put another way: you may not yet lock entire subpaths. This is for performance reasons, but there are plans to address this in future releases.

So the lockdown feature needs improvement.

[jtojnar]

Though reading wiki.gnome.org/Projects/dconf/SystemAdministrators

Presently (as of dconf 0.7.4) lockdown is only supported on a per-key basis. Put another way: you may not yet lock entire subpaths. This is for performance reasons, but there are plans to address this in future releases.

So the lockdown feature needs improvement.

I do not think that would be an obstacle to

I'd think if someone declared a key in the module that they'd want it to not change.

It would be useful for things like setting the NixOS wallpaper, which we want to be overridable.

[hedning]

So working from the code snippet from @jtojnar there would be two ways of specifying locks I think:

programs.dconf.dbs.<name> = {
  settings.<key> = "foo";
  locks = [];
  # Perhaps something like this too:
  lock = false; # whether to lock all keys
};

or

programs.dconf.dbs.<name>.<key> = {
  value = "foo";
  lock = true;
};

I don't think keys should be locked by default, as it's easy to revert keys back in eg. dconf-editor. As such putting all the locks in a separate array seems fine (though I guess we could support keys that are strings _or attrsets).

At that point we could build gsettingsOverrides on top of the dbs config.

Not sure if there's much point in supporting more than one setting file per db?

[jtojnar]

Initially, I was thinking about having options like programs.dconf.dbs.<name>.org.gnome.desktop.background.picture-uri but that would make string + attrset ambiguous. <name>.<schema>.<key> would probably be better, albeit the presence of periods would mean having to quote the schema id: <name>."org.gnome.desktop.background".picture-uri.

Personally, I like your second example (with the possibility of using the value directly when not locking) better, since I do not need many locks and think that having them next to the key they are locking would be most clear. But I can imagine someone wanting to lock everything, which would not be very comfortable this way.

Also note that GSettings values are typed so we might need to serialize arbitrary GVariants.

Not sure if there's much point in supporting more than one setting file per db?

Perhaps if they came from a different source (network drive). I would not bother with that.

What we probably do want is the ability to specify name of the user-db. And maybe setting some extra file-db for special profiles like gdm.

[jtojnar]

Not sure if there's much point in supporting more than one setting file per db?

Actually each database corresponds to a single binary file. (And possibly multiple source keyfiles in <db>.d directory but they are irrelevant for us.) Did you mean to write about profiles?

Hmm, using file-db pointing to a generated DB in Nix store might even be cleaner than using system-db and generating the file somewhere in /etc.

[hedning]

And possibly multiple source keyfiles in .d directory but they are irrelevant for us

Was referring to the source keyfiles, I can't come up with a reason to support more than one either.

[hedning]

Personally, I like your second example

It does look cleaner, and perhaps optimal if we support strings and attrsets.

albeit the presence of periods would mean having to quote the schema id

It looks like the keyfiles use the schema path, not id. Ie. /, though that still needs to be quoted.

[jtojnar]

It looks like the keyfiles use the schema path, not id. Ie. /, though that still needs to be quoted.

Yeah, just realized that. dconf works on lower level so it cannot translate the ids. The benefit is that the keys are no longer demarcated.

[jtojnar]

There is now a pull request to create a dconf db in GDM module. If we could just generalize this.

[chkno]

Re: Per-value locks and mass-lock tedium: In the unlikely event that many locks are needed this seems easy enough to handle with mapAttrs (_: v: { value = v; lock = true; })

[chkno]

Please keep in mind list-valued configuration: Dconf does not support merging list-valued keys. At least two important Gnome settings are list-valued: /org/gnome/shell/enabled-extensions and /org/gnome/settings-daemon/plugins/media-keys/custom-keybindings. For example, to enable two extensions a@a and b@b, this must be set to ['a@a','b@b']. It is quite hard for a@a and b@b to be added by different modules & end up with ['a@a','b@b'] at the end if dconf values are nix strings, but very easy if dconf values can be nix lists.