Created attachment 136881 [details] [review]
Allow overriding the default config via $GCONF_DEFAULT_SOURCE_PATH

This can point to a file to be used instead of
${sysconfdir}/gconf/2/path to determine the config sources used by
gconf_engine_get_default()/gconf_client_get_default(). In particular,
this will allow jhbuild to set up an environment in which jhbuilt
applications can see their own schemas, rather than only seeing the
schemas of system packages.

Patch looks good to me, fwiw.

One thing I was a little unsure about was conf->is_default getting dropped (in favor of checking if the address list is empty).

It's okay though, because it seems like the point of conf->is_default is to determine whether the client should specify the database or the client should have gconfd figure it out. Then there is this comment:

/* A list of addresses that make up this db
 * if this is not the default engine;
 * NULL if it's the default
 */

So there's already an invariant that is_default = TRUE implies addresses = NULL and is_default = FALSE implies addresses != NULL

Some previous discussion on this:

[15:44:32]  <danw> anyone given much thought to using gconf from
javascript yet? it seems like enough things don't wrap nicely that we're
going to have to use a bunch of C glue
[15:50:53]  <owen> danw: my initial take is that we probably need to write
our own gobject-based preferences api that wraps gconf
...
[15:52:08]  <danw> the big problem is that, particularly in the case where
the schemas aren't working right, you need to use some non-boxed struct
types
...
[15:58:45]  <owen> danw: of course, just fixing the schemas is easy enough
so it's not worth that much thought
[15:59:30]  <danw> what do you mean "just fixing the schemas is easy
enough"? force the user to build as root and install into /etc?
[16:00:34]  <owen> danw: A) my LD_PRELOAD blog post B) alternate scheme
that halfline came up with - I described it in some detail here yesterday
[16:00:36]  <halfline> danw: there's a tenative plan for fixing gconf to
work better wth jhbuild
[16:00:43]  <halfline> danw: let me find the conversatoin
[16:00:44]  <halfline> one sec
[16:01:26]  <danw> hm... i wonder if we can use
gconf_engine_get_for_address() to get gconfd to start monitoring our
schemadir...
[16:02:13]  <owen^ that's basically halfline's scheme, except that you
want to do it via envvar so it affects libraries and mutter
[16:02:41]  <owen> so that requires some sort of (hopefully simple)
extension to libgconf
[16:03:03]  <owen> and requires adding libgconf to the jhbuild - which
probably is fine, unless any distro is using gconf-dbus instead (afaik,
no)
[16:03:09]  <halfline> http://rstrode.fedorapeople.org/gconf-fixup.txt
[16:05:28]  <owen> danw: ideally, it would be something like
GCONF_SOURCE_ADDRESSES=include:/etc/gconf/path;xml:readonly:$sysconfdir/gconf/gconf.xml.defaults
[16:06:09]  <owen> or maybe it's fine to just hardcode what we expect to
be in /etc/gconf/path in the normal case
[16:07:33]  <owen> Hmm, or maybe
GCONF_SOURCE_PATH=$sysconfdir/gconf/path.jhbuild and then you don't have
to write any parsing code at all
[16:08:17]  <halfline> owen: still have to copy and paste the path file
parsing code i think
[16:08:35]  <owen> halfline: I'm pretty sure (not positive) that's linked
into libgconf
[16:08:50]  <owen> halfline: if not, it can be made so if we're changing
libgconf anyways
[16:10:20]  <owen> yeah, it's in libgconf
[16:10:28]  <owen> halfline: gconf_load_source_path()
...
[16:14:36]  <danw> halfline: are you working on this or should i?
[16:16:39]  <halfline> danw: not working on it atm
[16:17:24]  <halfline> danw: so feel free if you want to :-)

ok, looks like we do want to go with this patch, or something very much like it. ok to commit? is the variable name ok?

commit it :-) GConf doesn't really have a "maintainer" per se...

to be sure, it does fix your problem, right?

ok, committed