GNOME Bugzilla – Bug 646039
g_settings_list_children() returns child that cannot be opened
Last modified: 2013-10-24 19:37:51 UTC
g_settings_list_children() returns child that cannot be opened. Test case: from gi.repository import Gio for name in Gio.Settings.list_schemas (): schema = Gio.Settings (name) for key in schema.list_keys (): print (name, '%s%s' % (schema.get_property ('path'), key)) for child_name in schema.list_children (): child_schema = schema.get_child (child_name) for key in child_schema.list_keys (): print (name, '%s%s/%s' % (schema.get_property ('path'), child_name, key)) Expected result: prints out all the schema keys Observed result: Got error: GLib-GIO-ERROR **: Settings schema 'org.gnome.Empathy.accounts' is not installed Due to org.gnome.Empathy.gschema.xml on my system referring to a non-defined schema org.gnome.Empathy.accounts.
(glib 2.28.4-0ubuntu2)
seems like glib-compile-schemas should throw an error in this case...
Here is a similar case: gsettings list-recursively org.gnome.desktop.default-applications GLib-GIO-ERROR **: Settings schema 'org.gnome.desktop.default-applications.at' is not installed aborting... Aborted (core dumped)
Created attachment 185495 [details] [review] first approach to fixing this This patch represents a first approach to fixing this problem: If we encounter a <child schema="x"/> for undefined schema "x" then we throw an error. I think this is probably not good enough, since it will throw errors in the case that the schema is defined, but not yet. That will impact at least these modules: gnome-settings-daemon shell nautilus gedit libgnomekbd eog desktop brasero file-roller empathy ...surely many others I think I will have to add an extra phase to the compiler to do "checks" after each file, and enforce sanity at that point. Stay tuned.
commit 3498d58289ed833aeae59bfc76db0f5fa5840481 Author: Ryan Lortie <desrt@desrt.ca> Date: Fri Apr 8 01:47:52 2011 -0400 glib-compile-schemas: check for undefined refs For child schemas, verify that the named schema actually exists and issue a warning if not. This error in schema files will cause runtime errors when iterating over the list of child schemas and attempting to instantiate each one. This will move from being merely a warning to a hard error in the future. Bug #646039.
I don't close this bug because I have an uneasy feeling still, and this is a very difficult situation. The response to it could fall anywhere in the following range (from most strict to most permissive): - the patch as above - check that all <child> references are in the same file - the warning I just committed becoming an error Two questions arise: - do we support maintainers who use <child> with schema in another file shipped with the same package? - do we support maintainers who use <child> to refer to schemas installed by other modules that they depend on (with pkg-config check, for example)? This question is the same for enums, actually. In the first case, it is very clear that we must allow cross-file schema references. In the second case, we may also have to allow cross-directory schema references (since maybe your schema is in ~/install/share, but the package you depend on has its schema in /usr/share). Things get very very interesting now, since the schema compiler only sees one directory at a time. Right now this all "just works", and if you create cross-directory dependencies then they are just resolved at runtime (assuming they are not broken). In the future, the situation could become substantially more ugly, particularly when you consider that the following situation may occur: - schema file Y depends on schema file X - schema file X is in /usr/share - schema file Y is in ~/install/share - run the compiler on ~/install/share. We check for X in /usr to verify that it's all OK. - remove X and rerun the compiler on /usr/share - now we have a broken link, even though the compiler verified (at the time) that everything was okay. I guess this is not too much unlike shared libraries (or symbols therein) going missing and we have no graceful solution for that either. At least in that case we have some sane explicit ways to declare the dependencies. GSettings is presently lacking this capability. I'd impose a strict self-contained-file rule at this point, but I'm fairly sure it would break quite a lot of existing users (who put their child schema definitions in separate files installed by the same package). Needs some thinking...
This is fixed in 27898916d42f0e827cf2e99c12ab7bcd0a3712a9