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
