Re: GConf in Debian Sarge

On Fri, 2004-06-25 at 05:27, Josselin Mouette wrote:
> Le ven, 25/06/2004 à 00:08 -0400, Havoc Pennington a écrit :
> > 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.
> 
> Question: what happens when the admin modifies one file? When the
> package is upgraded, the defaults are removed then regenerated from
> the .schemas files. Are the administrator's changes kept in this case?
> If so, I still find it ugly, but we could keep it that way.

The changes should be kept (since the --makefile-install-rule is simply
writing schema objects into the gconf source, it's not removing any
existing values in the source)

> > 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.
> 
> That's close to what I suggested first, but it's impossible to manage
> for installed packages, unless we *move* stuff from /etc to /var upon
> upgrade, which is dangerous. If we just change the defaults this way,
> installed packages will try to remove their defaults from /var/lib while
> they have installed them in /etc.

Removing from a place where the defaults aren't should not cause an
error, does removing from both places solve the problem?

> Of course we must keep a directory for defaults in /etc.

Good, that's the main point. If you guys want to move the installed
schemas to /var/lib that feels reasonable to me, let's do it upstream
too.

> Yes, I'm pretty confused, especially WRT what gconftool does in the
> postinst. It seems to put the schemas in the /etc/gconf/gconf.xml.
> defaults/schemas/apps structure, but it also puts some defaults in /etc/
> gconf/gconf.xml.defaults/apps.

It should not put any defaults there. The files created there should be
for the metadata that maps a setting to its schema. i.e. 
the key "/schemas/apps/foo/bar" is normally associated with
"/apps/foo/bar"

However this mapping need not be 1-to-1, e.g. in some cases you have 
apps that dynamically create /apps/foo/bar/1, /apps/foo/bar/2, things
like that, and they use /schemas/foo/bar/something for all of those
keys.

This is different from what an admin would put in gconf.xml.defaults.
The admin would set a *value* for /apps/foo/bar, rather than associating
a schema with it.

Havoc