Re: GConf in Debian Sarge

[Havoc Pennington <hp redhat com>]

On Sun, 2004-06-20 at 16:48, Ross Burton wrote:
> 
> We talked about applications not getting change notifications, and
> agreed it was a minor problem.  In the usual case of .schemas changing,
> the binary is also being changed, so users would restart the application
> anyway.  If they don't restart the application they also don't get the
> new keys forced on them, so all is good.
> 
> The patch Josselin Mouette created to do this is attached
> (gconfd_sighup_reload.diff)

The patch does the reload in the signal handler - probably not good,
especially in this case if you're installing a series of packages
getting a second signal is not unlikely.

Needs to just write to a pipe or something to wake up the mainloop and
do the reload there... I'm trying to think of a program with an example
of this, dbus-daemon does it but that doesn't use GMainLoop.

> > This is fine with me as long as jhbuild doesn't catch on fire. If this
> > is committed to GNOME CVS, I would expect someone to clean out their
> > GNOME prefix, clean out their CVS tree, check out and build from
> > scratch, and be sure things build and appear to work right. Again also
> > post the exact patch, but the main thing in my mind is an assurance that
> > the above testing has happened.
> 
> As I see it, there is no problem.  Schemas are only registered at
> install time, so changing the location schemas are written to does the
> right changes to the Makefiles.  The patch to which gconftool writes the
> defaults too is of course up to the installed gconftool.

If you're sure, I'll leave it to the release team to suitably punish you
if the build breaks. ;-)

> As I see it, defaults and mandatory values as generated by gconftool in
> postinstall scripts are not configuration files which users should
> change, but system defaults.

Why are packages changing defaults/mandatory though (outside of
/schemas?)

Factory defaults should be changed in packages by patching the .schemas
file.

If we have to make a change here I'd add a "schemas" source that's read
before the "defaults" source, and leave "defaults" in /etc

However I'm pretty concerned that by changing anything here we are
making things even more confusing than they already are. The
defaults/schemas mess is the single most confusing thing about gconf.

http://log.ometer.com/2004-03.html#1

Of course changing this for Debian only or changing it in one way now
and another way later will make the confusion worse. We should be sure
we're going in the right direction.

>   This is because if someone sets a default
> value in /etc/gconf/gconf.xml.defaults (changing a schema-installed
> default) and then the package is upgraded, the admin-set default will be
> overridden. 

That isn't the case I don't think. The admin default is /foo/bar. The
schema default is stored in the schema object at /schemas/foo/bar. The
package should not touch the admin default.

Here's a mail that tries to explain it:
http://mail.gnome.org/archives/gconf-list/2003-December/msg00007.html

>  This is worked around with recent GConfs by doing:
> 
> include /etc/gconf/2/local-defaults.path

The comment in default.path.in should explain this better. The point is
to let people insert new _path_ entries. But gconf.xml.defaults is still
usable for local config. New path entries could be used to e.g. have a
path that is per-user or per-host.

> in the path file, so that system administrators should populate this
> file and point it at their own defaults tree.  This implies that the
> current defaults and mandatory trees in /etc/gconf are not configuration
> files after all, but simply the package defaults.  Thus, /usr or /var
> are better locations in our opinion.

The package defaults are intended to be in the .schemas

> Oh, and I've a one-line patch to add doc/FAQ.txt to the distribution. 
> Can I commit this?

Sure, thanks.

Ugh, you are reminding me that gconf needs a focused decomplexification
and decruftification. ;-) The time isn't quite right yet though, I think
first we line up D-BUS and then we can do it in a desktop-independent
and robust way.

Havoc