Le lun 21/06/2004 à 00:34, Havoc Pennington a écrit :
The patch does the reload in the signal handler - probably not good,
especially in this case if you're installing a series of packages
getting a second signal is not unlikely.
Yes, that's what I thought. However gconfd is quite fast to reload its
databases so it won't hassle the system (we have much more obnoxious
stuff in packages postinsts, see e.g. update-mozilla-chrome). Of course
I'd like to see it done a better way.
Needs to just write to a pipe or something to wake up the mainloop and
do the reload there... I'm trying to think of a program with an example
of this, dbus-daemon does it but that doesn't use GMainLoop.
An example would be appreciated.
As I see it, defaults and mandatory values as generated by gconftool in
postinstall scripts are not configuration files which users should
change, but system defaults.
Why are packages changing defaults/mandatory though (outside of
/schemas?)
Factory defaults should be changed in packages by patching the .schemas
file.
I've already been told not to do that, but that's what Debian are
usually doing. However, if the system administrator wants to change
these defaults, he has to run gconftool again.
Furthermore, the defaults are generated automatically by gconftool from
the schemas, and this generation takes place in /etc, which is very bad.
This has to go to /var/lib.
If we have to make a change here I'd add a "schemas" source that's read
before the "defaults" source, and leave "defaults" in /etc
Why should it be read before? Shouldn't defaults set by the system
administrators be read before defaults introduced by the schemas?
However I'm pretty concerned that by changing anything here we are
making things even more confusing than they already are. The
defaults/schemas mess is the single most confusing thing about gconf.
http://log.ometer.com/2004-03.html#1
Of course changing this for Debian only or changing it in one way now
and another way later will make the confusion worse. We should be sure
we're going in the right direction.
That's exactly why we are asking.
That isn't the case I don't think. The admin default is /foo/bar. The
schema default is stored in the schema object at /schemas/foo/bar. The
package should not touch the admin default.
But gconftool already creates %gconf.xml files in
/etc/gconf/gconf.xml.defaults. Managing these files for both
schema->default generation and administration is a nightmare.
Regards,
_______________________________________________
gconf-list mailing list
gconf-list gnome org
http://mail.gnome.org/mailman/listinfo/gconf-list
