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

Re: GConf in Debian Sarge



Le sam, 26/06/2004 à 00:57 -0400, Havoc Pennington a écrit :
> > Question: what happens when the admin modifies one file? When the
> > package is upgraded, the defaults are removed then regenerated from
> > the .schemas files. Are the administrator's changes kept in this case?
> > If so, I still find it ugly, but we could keep it that way.
> 
> The changes should be kept (since the --makefile-install-rule is simply
> writing schema objects into the gconf source, it's not removing any
> existing values in the source)

OK, so I'm fine with keeping the defaults in /etc, at least for sarge.

> > That's close to what I suggested first, but it's impossible to manage
> > for installed packages, unless we *move* stuff from /etc to /var upon
> > upgrade, which is dangerous. If we just change the defaults this way,
> > installed packages will try to remove their defaults from /var/lib while
> > they have installed them in /etc.
> 
> Removing from a place where the defaults aren't should not cause an
> error, does removing from both places solve the problem?

Yes, but it's not easy to tell the packages to do that. We are talking
about existing prerm scripts that can't be modified. Otherwise, that
means upgrading all packages depending on gconf at once, which is
completely unreasonable.

> > Of course we must keep a directory for defaults in /etc.
> 
> Good, that's the main point. If you guys want to move the installed
> schemas to /var/lib that feels reasonable to me, let's do it upstream
> too.

Well, that's something I'd like to see in GNOME 2.8 or 2.10. If we all
agree on a location and a proper transition, this will be the best for
everyone.

> > Yes, I'm pretty confused, especially WRT what gconftool does in the
> > postinst. It seems to put the schemas in the /etc/gconf/gconf.xml.
> > defaults/schemas/apps structure, but it also puts some defaults in /etc/
> > gconf/gconf.xml.defaults/apps.
> 
> It should not put any defaults there. The files created there should be
> for the metadata that maps a setting to its schema. i.e. 
> the key "/schemas/apps/foo/bar" is normally associated with
> "/apps/foo/bar"

OK, thanks for the explanations. That means packages can't ship defaults
files here without breaking the policy, but if we can set defaults in
schema files and the admins can set defaults directly in these
directories, then this achieves the same goals as classical
configuration files, even if it's a bit more complicated. 

So I'd say we should let the defaults where they are currently, and work
on an implementation for GNOME 2.8 or 2.10.

I'll try to upload soon a new gconf package with only the SIGHUP patch,
and we can then update debhelper to move the schemas to /usr and make
use of that SIGHUP.
-- 
 .''`.           Josselin Mouette        /\./\
: :' :           josselin.mouette@ens-lyon.org
`. `'                        joss@debian.org
  `-  Debian GNU/Linux -- The power of freedom

Attachment: signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=


Reply to: