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. > 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. See e.g. exim4: the config file is generated from a set of files contained in the package or provided by the administrator. And it is generated in /var. > 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. 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. > 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. Of course we must keep a directory for defaults in /etc. > 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... ;-)) 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. > 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. This solution seems a lot cleaner, but it probably needs a lot of changes in the gconf code. Regards, -- .''`. Josselin Mouette /\./\ : :' : josselin mouette ens-lyon org `. `' joss debian org `- Debian GNU/Linux -- The power of freedom
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=