Re: GConf in Debian Sarge

[Havoc Pennington <hp redhat com>]

On Tue, 2004-06-22 at 04:53, Josselin Mouette wrote:
> Le mar 22/06/2004 �0:36, Ross Burton a �it :
> > Havoc's points and arguments for not moving the installed defaults to
> > /var make sense to me, and I now don't see any problems with the current
> > setup in /etc/gconf.  It's a small problem that there are
> > package-generated defaults in /etc which shouldn't be modified by the
> > local administrator,
> 
> If they shouldn't be modified, they shouldn't go in /etc.

Really, this is identical to shipping a config file with various
settings, and the local admin changes some and some of them remain what
shipped with the OS.

gconf.xml.defaults/* is conceptually one big config file.

Many packages have a default config file and then can include site-local
changes in a "local.conf" or a ".d" directory; in that case, do you put
the default config file in /var? The gconf case is the same.

> > but these are restricted to a subset of the
> > defaults tree (/schemas)
> 
> Wrong. The defaults are also written to the other directories. I don't
> know whether this is a wanted behaviour from gconftool, but that's what
> it does.

Possibly you're confusing the schema objects with the schema names.
http://mail.gnome.org/archives/gnome-deployment-list/2003-December/msg00001.html tries to explain this.

> Maybe a compromise would be to move only
> /etc/gconf/gconf.xml.defaults/schemas to /var and setup a symlink. If
> these files must not be modified by the administrator, the directory
> structure has to reflect it.

I think you guys missed one of my suggestions. If you want to move the
installed schemas to /var, what you need to do is put this in
/etc/gconf/2/path:

xml:readonly:/etc/gconf/gconf.xml.defaults
xml:readonly:/var/lib/gconf/gconf.xml.schemas

Then have the schemas install to gconf.xml.schemas, and have admins edit
gconf.xml.defaults.

However, moving gconf.xml.defaults to /var is wrong. If you want the
package-managed stuff in /var then OK, but don't move gconf.xml.defaults
there, that is just broken.

Again, if you have a package with:
 do-not-modify-this-config-file.conf
which includes:
 site-local.d
 site-local.conf

Then do-not-modify-this-config-file.conf is the same as
"gconf.xml.schemas" and site-local.* is "gconf.xml.defaults"

Right now gconf is set up (as many programs are) where it doesn't really
have the "includes", and the normal thing to do in that case is to just
toss the whole thing in /etc

Now I can't think of an example of putting
do-not-modify-this-config-file.conf in /var ... but I think it's clear
that if you *are* going to do that, it should only be that file, not the
site-local.* stuff.

However, I'll repeat my caveat on this whole thing: the #1 problem with
gconf today is that most admins do not understand the
defaults/schemas-files/schemas-objects/installation/etc. mess (and based
on this thread, neither does anyone else... ;-)) 

So we should be really careful that whatever we're doing makes this all
simpler, not harder. If you guys are going to spend a lot of time on
this, I'd say a suggestion like the one in my blog to simply not install
schemas to the gconf sources at all might be the way to go.
(http://log.ometer.com/2004-03.html#1) I don't *know* this is the way to
go (there are certain problems we'd have to solve - some gconf keys are
shared by a bunch of apps is the main one :-/) but it'd be worth
thinking about.

Each app would somehow need to know which .schemas to load up, and we'd
probably have to cache the .schemas for speed.
We could just have the .schemas in /usr/share/gconf/apps/foo/bar.schemas
so e.g. libgconf (not gconfd) when loading a key at /apps/foo/bar or
below would load that file. We could do an mmap() cache of the defaults,
much like the icon theme cache that's been discussed on
desktop-devel-list/gtk-devel-list.

Havoc