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 _______________________________________________ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
