On Tue, 2004-06-22 at 04:53, Josselin Mouette wrote: > Le mar 22/06/2004 Ã 00:36, Ross Burton a Ãcrit : > > 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
