On Sun, 2004-06-20 at 20:53, Havoc Pennington wrote:
> On Sun, 2004-06-20 at 14:01, Ross Burton wrote:
> > Firstly, we've a patch to gconfd[1] so that we can send a HUP signal to
> > force it to reload the configuration. This happens in the postinst
> > script of any GConf-using package, and means the user doesn't have to
> > kill gconfd before the schemas are applied (which is the cause of many
> > bug reports). The alternative is to send a TERM signal, but this is
> > rather evil.
>
> TERM should in fact work fine, and does as far as I know. gconfd is
> designed to be killable with impunity.
>
> The problem with both this and HUP is that it doesn't 100% work; apps
> that are already running will not get change notifications of any
> changes to the schemas. To make that work you'd have to cache
> everything, reload, and diff old vs. new. Not worth it probably.
>
> Anyhow, I'd need to see the exact patch, but it sounds OK in principle.
We talked about applications not getting change notifications, and
agreed it was a minor problem. In the usual case of .schemas changing,
the binary is also being changed, so users would restart the application
anyway. If they don't restart the application they also don't get the
new keys forced on them, so all is good.
The patch Josselin Mouette created to do this is attached
(gconfd_sighup_reload.diff)
> > Next, we're taking the plunge and moving the .schemas files from
> > /etc/gconf/schemas to /usr/share/gconf/schemas. Files in /etc are
> > treated specially in Debian and dpkg will allow the user to keep the old
> > schemas instead of installing the new files, which is confusing and can
> > potentially break software. We're going to implement this by moving the
> > schema files at package build-time. It would be great if this change
> > was in GConf 2.8, as it should only need a patch to the
> > AM_GCONF_SOURCE_2 autofoo snippet (and then becomes a packaging issue).
>
> This is fine with me as long as jhbuild doesn't catch on fire. If this
> is committed to GNOME CVS, I would expect someone to clean out their
> GNOME prefix, clean out their CVS tree, check out and build from
> scratch, and be sure things build and appear to work right. Again also
> post the exact patch, but the main thing in my mind is an assurance that
> the above testing has happened.
As I see it, there is no problem. Schemas are only registered at
install time, so changing the location schemas are written to does the
right changes to the Makefiles. The patch to which gconftool writes the
defaults too is of course up to the installed gconftool.
> > Finally, we're going totally bonkers and relocating the installed
> > defaults/mandatory keys from /etc/gconf/ to /var/lib/gconf/defaults[2],
> > whilst keeping /etc/gconf/system.defaults for administrators to play
> > with. The patches used to implement this are available online[3]. They
> > appear to work and results in full FHS-compliant GConf behaviour (also a
> > cause of several bug reports).
>
> I don't understand this, since defaults/mandatory to me are config files
> in the classical spirit of /etc
> Maybe explain a bit more?
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. This is because if someone sets a default
value in /etc/gconf/gconf.xml.defaults (changing a schema-installed
default) and then the package is upgraded, the admin-set default will be
overridden. This is worked around with recent GConfs by doing:
include /etc/gconf/2/local-defaults.path
in the path file, so that system administrators should populate this
file and point it at their own defaults tree. This implies that the
current defaults and mandatory trees in /etc/gconf are not configuration
files after all, but simply the package defaults. Thus, /usr or /var
are better locations in our opinion.
The bulk of this work is at the moment done in dh_gconf, a helper script
ran at package build time. At the moment this simply adds the gconftool
calls to install the schemas, but it will move the schemas files to /var
and tell gconftool to install the defaults into /var. Finally the gconf
/etc/gconf/2/path file had the extra paths:
...
# Finally, look at the systemwide defaults
# These are the defaults overriden by a package or the sysadmin
xml:readonly:@EXPANDED_SYSCONFDIR@/gconf/system.defaults
# This is the location where dh_gconf puts the defaults
xml:readonly:/var/lib/gconf/defaults
# Finally, for compatibility, the old location for defaults
xml:readonly:@EXPANDED_SYSCONFDIR@/gconf/gconf.xml.defaults
gconftool --get-default-source will be returning
/etc/gconf/gconf.xml.defaults for now, for compatibility with older
packages, which currently use gconftool --get-default-source to find the
schema files and un-install them.
Obviously if this was taken upstream the patches would need to be
changed somewhat, as they assume the upstream paths.
Hopefully Josselin will reply and clarify any points I'm failing to
make, and add any I missed.
Oh, and I've a one-line patch to add doc/FAQ.txt to the distribution.
Can I commit this?
Ross
--
Ross Burton mail: ross burtonini com
jabber: ross burtonini com
www: http://www.burtonini.com./
PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
--- GConf-2.6.1/gconf/gconfd.c.orig 2004-06-15 11:45:14.000000000 +0200
+++ GConf-2.6.1/gconf/gconfd.c 2004-06-15 11:56:06.000000000 +0200
@@ -397,7 +397,6 @@
break;
case SIGTERM:
- case SIGHUP:
enter_shutdown ();
/* let the fatal signals interrupt us */
@@ -410,6 +409,18 @@
gconf_main_quit ();
break;
+ case SIGHUP:
+ --in_fatal;
+
+ gconf_log (GCL_INFO,
+ _("Received signal %d, reloading database"), signo);
+
+ /* Regenerate the databases from the default sources */
+ shutdown_databases ();
+ init_databases ();
+ gconf_server_load_sources ();
+ break;
+
case SIGUSR1:
--in_fatal;
Attachment:
signature.asc
Description: This is a digitally signed message part