After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 662438 - Support for multiple dconf configuration files in $HOME
Support for multiple dconf configuration files in $HOME
Status: RESOLVED FIXED
Product: dconf
Classification: Core
Component: dconf
git master
Other Linux
: Normal normal
: ---
Assigned To: dconf-maint
dconf-maint
Depends on:
Blocks:
 
 
Reported: 2011-10-22 02:31 UTC by Josh Triplett
Modified: 2012-03-07 23:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
engine: allow multiple user databases (10.63 KB, patch)
2012-03-04 02:29 UTC, Allison Karlitskaya (desrt)
committed Details | Review

Description Josh Triplett 2011-10-22 02:31:42 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.
Comment 1 Allison Karlitskaya (desrt) 2012-03-04 01:01:38 UTC
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'.
Comment 2 Allison Karlitskaya (desrt) 2012-03-04 01:03:38 UTC
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.
Comment 3 Allison Karlitskaya (desrt) 2012-03-04 02:29:04 UTC
Created attachment 208932 [details] [review]
engine: allow multiple user databases

Drop the long-standing assumption that there will be exactly one user
database.
Comment 4 Josh Triplett 2012-03-04 04:51:07 UTC
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!
Comment 5 Allison Karlitskaya (desrt) 2012-03-07 22:57:18 UTC
Committed.  Will roll a release soon.
Comment 6 Josh Triplett 2012-03-07 23:15:30 UTC
Thanks!