Re: GConf in Debian Sarge

[Havoc Pennington <hp redhat com>]

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.

> 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.

> 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?

> So, do these changes look good, and is there any real reason why they
> cannot be integrated into GNOME 2.x?  Jeff Waugh has stated that he
> doesn't see these as ABI-breaking patches to me, so can be in the 2.x
> release set.

Sounds reasonable in principle, would like Mark to sign off as well, and
of course we have to look at the patches.

Havoc