Re: GConf in Debian Sarge



Josselin Mouette wrote:
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.

    It is BAD idea doing this in the signal handler, it is well known behaviour that
running any non-reentrant code within signal handler can cause signicicant problem.
I can across this problem just this month in gconfd-2, See
http://bugzilla.gnome.org/show_bug.cgi?id=143590

Saying gconfd is quite fast, one talk about 100th mileseconds, but with a gigabytes
processer, even 10th mileseconds can have hundredthe signals events.

Sorry don't have a better suggestion at the moment, but certainly want to point up
the slippery slope :)

-Ghee


  
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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]