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 616310 - gsettings-schema-convert should convert underscores to dashes
gsettings-schema-convert should convert underscores to dashes
Status: RESOLVED FIXED
Product: GConf
Classification: Deprecated
Component: gsettings
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GConf Maintainers
GConf Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-04-20 16:24 UTC by Bastien Nocera
Modified: 2010-07-08 07:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bastien Nocera 2010-04-20 16:24:34 UTC
> - gsettings-schema-convert does not convert underscores to dashes (and
> > it disallows underscores in key names)
> 
> Vincent wrote that conversion script. I guess he just didn't get
> around to that yet. Patch welcome, I'm sure.  It should probably be an
> explicit --convert-names
> option though, since there is some risk of collisions.
Comment 1 Vincent Untz 2010-04-20 17:45:55 UTC
Note that we can't do this by default until we're 100% sure the app will not use the gconf backend. Else, the gconf backend won't be able to find the key in gconf.

I'll add an option, but it shouldn't be used for now :-)
Comment 2 Bastien Nocera 2010-04-20 17:50:04 UTC
(In reply to comment #1)
> Note that we can't do this by default until we're 100% sure the app will not
> use the gconf backend. Else, the gconf backend won't be able to find the key in
> gconf.

You're telling me I should be installed *both* the GConf and GSettings schemas? Either you use Gconf, or you use GSettings with GConf as the backing store.

You could add the option, and make sure you print a warning about the key name without it.

Personally, I'd change the keyname and setup gsettings-data-convert for it.

> I'll add an option, but it shouldn't be used for now :-)
Comment 3 Vincent Untz 2010-04-20 18:07:34 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > Note that we can't do this by default until we're 100% sure the app will not
> > use the gconf backend. Else, the gconf backend won't be able to find the key in
> > gconf.
> 
> You're telling me I should be installed *both* the GConf and GSettings schemas?
> Either you use Gconf, or you use GSettings with GConf as the backing store.

Oh, it's not necessary to install both schemas if you migrated all the code to gsettings. But what you want with this backend is to access your old data in gconf, without migration.

> Personally, I'd change the keyname and setup gsettings-data-convert for it.

Hrm. I'm not sure we want this: gsettings-data-convert will be used only once, and if you migrate the date to the gconf backend, it won't get migrated to the dconf backend once it's available. And the end goal is to migrate the data to the dconf backend.
Comment 4 Matthias Clasen 2010-04-20 23:34:24 UTC
You can certainly do multiple data migrations, by installing differently named keyfiles in /usr/share/gconf/gsettings, but as Vincent says, that was not quite the intended use.
Comment 5 Vincent Untz 2010-07-08 07:26:35 UTC
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.