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 656262 - Support loading conversion files from user-specified directory
Support loading conversion files from user-specified directory
Status: RESOLVED FIXED
Product: GConf
Classification: Deprecated
Component: gsettings
2.32.x
Other Linux
: Normal normal
: ---
Assigned To: GConf Maintainers
GConf Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-08-10 09:31 UTC by Jim Nelson
Modified: 2011-08-15 23:41 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jim Nelson 2011-08-10 09:31:49 UTC
Our app is built to allow developers to run the compiled binary from the build directory.  However, gsettings-data-convert will only read the key files from $(DATADIR)/GConf/gsettings, requiring the app to be installed before running the conversion tool.  (We've elected to run gsettings-data-convert in our application, as specified at http://developer.gnome.org/gio/2.26/ch26s07.html)

It would be nice if gsettings-data-convert allowed for additional directories to be specified (either on the command-line or an environment variable, akin to GSETTINGS_SCHEMA_DIR).
Comment 1 Allison Karlitskaya (desrt) 2011-08-15 16:02:24 UTC
hi Jim

I just pushed a branch that rearchitects things a bit and implements two main features:

  1) all conversion dirs in XDG_DATA_DIRS are scanned

  2) a --file option to let you specify a conversion script directly


    http://git.gnome.org/browse/gconf/log/?h=migration-changes


Either one of these on its own is probably sufficient for what you're trying to do.  I sort of like the idea of doing both.

These patches introduce some difficult questions with respect to the timestamp that gets stored in the keyfile to prevent needless rescanning of the directory.  For example, if you are only doing a single --file then it doesn't make sense to update the timestamp.  I deal with that right now by running the updates from the directory at the same time (so that we can update the timestamp).

It might make sense to just drop this cache code entirely.  Doing a 'ls' on the directory and seeing that all of the entries are already in a hashtable can't be so expensive, and it would help us avoid some annoying edgecases...
Comment 2 Allison Karlitskaya (desrt) 2011-08-15 23:41:21 UTC
Okay.  Pushed all of that stuff.