Re: [Evolution-hackers] Evo master dumps core: missing GConf key

[Matthew Barnes <mbarnes redhat com>]

On Tue, 2009-11-24 at 19:15 -0500, Paul Smith wrote:
> I am, yes.  But I don't get your last sentence: is there a way to use
> these without screwing up the GConf settings (using an alternate gconf
> database for example)?

In fact there is: see the "Configuration Sources" section of [1].

But I think the Makefile.am logic is oriented to the more common case,
where you have a system-wide, let's call it "official" Evolution install
and one or more private builds -- possibly of differing versions -- for
testing or hacking or whatever.  All of these builds, regardless of
installation prefix, by default install their GConf schema files to
~/.gconf.

So I assume the Makefile.am logic is trying to determine whether it's an
"official" build or not, and only allow "official" builds to overwrite
the previous schema files in ~/.gconf.  But in this age of pre-compiled
binary distribution the policy seems outdated, unless I'm totally off
the mark here.  Most distros block "make install" from installing schema
files and do it themselves in a "post-install" phase.

If someone on the list is reading this and knows more about it, please
do jump in here.  The GConf schema install policy is clearly an idiom
among GNOME modules, but I'm fuzzy on the origins and rationale for it.

[1] http://projects.gnome.org/gconf/


> On the other hand, I actually do agree that running "make install"
> should NOT mess with your GConf settings; that definitely feels wrong.
> I was actually thinking that running "evolution" (the first time) would
> handle the transitions for you.

When you say "GConf settings", keep in mind the distinction between the
-value- of a GConf key and the -schema- for a GConf key.  The schema
provides the key's type, default value, and a translated description of
what it's used for.  The -user- sets the value (what I assume you mean
by "setting").  Installing a schema file never alters the values.  The
problems arise when the value and schema are inconsistent (e.g. value is
a string, schema expects an integer).  Evolution can't handle that.


> Next question: what's the right thing to do with bugs or issues I find?
> Do they go in bugzilla, even though the code is not released yet?  Or do
> you prefer to see issues here on this list?

You mean bugs or issues in git master?

Use your best judgment.  Safe answer is always Bugzilla.  But if it's
something that worked yesterday and now suddenly doesn't (build breakage
or some other careless boo-boo), posting to the list will usually get
you a quick response.

Matthew Barnes