GNOME Bugzilla – Bug 628937
gracefully handle broken schemas
Last modified: 2010-09-27 15:14:50 UTC
Created attachment 169646 [details] [review] Make glib-compile-schemas handle broken schema/override files Currently glib-compile-schemas fails when one schema/override is incorrect. This is bad because: - One application can install a schema that stops all the other schemas from working - The overrides file could reference software you may have installed, for example a theme package may contain overrides for a number of applications and they may not be installed. The attached patch makes glib-compile-schemas ignore schemas/overrides and single override lines that do not work. A new --strict flag has been added to match the existing behaviour (although even with --strict overrides are allowed to refer to schemas that are not installed). Note that the new/updated strings are not marked for translation due to the string freeze. A symptom of an override causing other applications to break is here: https://bugs.edge.launchpad.net/ubuntu/+source/ubuntu-artwork/+bug/621507
Created attachment 169648 [details] [review] Make glib-compile-schemas handle broken schema/override files Updated to use fprintf, not g_message for new output
we've had this issue before and we decided not to deal with it due to the excessive amount of parser-rewriting it would require... in general, it does seem odd to install intentionally broken files by default and rely on the error-backout code to save you (ie: it sounds like you intend to install override files for packages that may not themselves be installed).
Installing override files for non-installed packages may be a convenient thing to support, in fact. I can easily imagine someone wanting to do a my-super-duper-gnome-mods package that installs override files for all of gnome...
The example that triggered this was the ubuntu-artwork package which overrides the default theme for a number of applications. However users that didn't have empathy (first affected package that has migrated to gsettings) installed would hit the problem. There is also a synchronisation problem - if a schema changes but the override doesn't at the same time you will see the same problem. The worst problem (not yet seen, but it will happen) is if someone installs a random package from the Internet with a broken schema - you will not be able to update your cache for any of your other applications.
There are two issues here, I think: 1) dealing with invalid .xml 2) overrides for schemas that don't exist For the first issue, I think a --strict makes sense. Displaying warning messages probably makes sense too, even in the non-strict case (or maybe as an alternative to strictness). For the second issue, if we decide that it is valid to have overrides without the corresponding schema being installed, then I think we should not consider it to be invalid in any way (ie: --strict has no effect here, because what you are doing is strictly correct).
Sounds right to me
commit 7f925264813be92b445a4aa61b88128e15bb72e7 Author: Ryan Lortie <desrt@desrt.ca> Date: Mon Sep 27 10:27:11 2010 -0400 Bug 628937 - gracefully handle broken schemas Implement the first of two features requested in the bug: when encountering a broken .xml schema file, back out the changes in that file and continue to parse other files. This prevents a single broken .xml file from messing up GSettings for everyone else. Add a --strict option to get the old behaviour. Use this from the test cases. commit 90ccb5a4cd34e983909a0a253f1e86cec35482dc Author: Ryan Lortie <desrt@desrt.ca> Date: Mon Sep 27 11:10:11 2010 -0400 Bug 628937 - gracefully handle broken schemas Implement the second feature requested in the bug: silently ignore override files that attempt to override schemas that are not currently installed. Also, support 'strictness' being optional for other errors when parsing override files (ie: inability to open the file, unknown key name, parse errors, out of range). We don't completely back out the file in this case — as that is difficult with the current implementation — but just ignore the override for the single key.