GNOME Bugzilla – Bug 662438
Support for multiple dconf configuration files in $HOME
Last modified: 2012-03-07 23:15:30 UTC
[Filing as discussed with desrt on IRC.] I currently keep portions in my home directory in git, notably many of my configuration files. To handle gconf, I have a ~/.gconf.path which adds a new gconf source xml:readonly:$(HOME)/.gconf.shared , so that I can put settings in there that I want to share across systems (and check into version control). (Not perfect, since it makes those shared settings mandatory, but it works.) To do something similar with dconf, I'd like to have a way to split dconf settings into multiple dconf configuration files in $HOME. That way, I can put the settings I want to share in a separate file from the rest, and check those settings into git. Ideally, I'd like to have both of the dconf databases work read/write, with different sets of keys stored in each; that way, changes made via applications (or dconf-editor) show up in "git status" as changes to the shared dconf settings. However, if necessary I could live with something that matches the approach I use now with gconf, which requires manual updates to the shared configuration. desrt suggested implementing this via the DCONF_PROFILE environment variable, which could specify multiple dconf databases, or the path to a user-controlled configuration file specifying the databases and corresponding keys.
so my latest thinking is that the profile file would look something like this: user-db user system-db system path-db /some/path where each prefix means: user-db: a named database in the user's namespace of databses system-db: a named database in the system's namespace of databases path-db: a path to a dconf database, updates and change notification unsupported we'd handle backcompat by making the default case be that the first item in the list ends up with implicit 'user-db' and the others with implicit 'system-db'.
next problem is the ability to express the contents of the file directly in the DCONF_PROFILE environment variable. possibly we could use a different environment variable for this purpose. then we have another possible issue of figuring out if we should support dconf profile files in the user's homedirectory.
Created attachment 208932 [details] [review] engine: allow multiple user databases Drop the long-standing assumption that there will be exactly one user database.
I built dconf with this patch and tested it. It seems to work. I created two dconf profiles, one with user DBs "user1" and "user2", and the other with just "user2". I used the first profile to write a key to user1 and read it back, and that worked fine. I then used the second profile to write a key to user2, and the first profile to read it back, which worked fine as well. I tested overridding a key by using the first profile to set the same key in user1 that I already set in user2; reading it back correctly gave the overridden value from user1. I could then reset that key in user1 and I'd get the value from user2 again. I did discover that locks set in the "user2" DB didn't get respected; I used "dconf update" to create a user2 DB with a locked key /somepath/lockedkey, but I could still use the first profile to write to /somepath/lockedkey in user1. However, for the purposes of this bug report I don't care strongly about locked keys; I'd love to see a fix at some point, but given that all the other functionality works perfectly, I don't think this should block committing the patch. Thanks again for writing this!
Committed. Will roll a release soon.
Thanks!