rpms/regexxer/devel regexxer.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2

[Michael Schwendt]

On Wed, 05 Oct 2005 20:38:23 -0700, Toshio Kuratomi wrote:

> > Hmm, okay, this tracks back to a private collection of RPM scriptlet
> > hints by Toshio Kuratomi copied into the Wiki.
> > 
> > Mark McLoughlin from Red Hat commented on the GConf2 scriptlets on "Wed,
> > 02 Mar 2005 08:59:48 +0000" on fedora-maintainers list in the following
> > rather vague way:
> > 
> >     [...] and we should probably also be doing killall -HUP gconfd-2 or
> >     something so the daemons see the new schemas.
> > 
> > Seeing the word "probably" and seeing that none of the packages installed
> > on my Rawhide machine does this, I find it questionable.  This would
> > signal *all* running gconfd-2 processes (also user's) to reload all
> > databases. I don't like it when package installation "touches" user
> > processes. 
> 
> The gconf daemon needs to refresh its knowledge of the schemas when
> they're updated.

Is this a definite MUST or a SHOULD? Packages in Fedora Core don't send
SIGHUP to all gconfd-2 processes. Hence the question.

> Otherwise, opening up a program that's just been
> updated with a different schema could run into problems. 

Does gconfd-2 load all schema files upon restart? Or does it load
schema files only as needed?

> The gconfd-2
> process is run by a user, but its purpose is to supply configuration
> information to a program.  The gconf daemon needs to be alerted to the
> fact that the schemas have changed so it can reload them.
> 
> > This SIGHUP features is implemented since July 2004. Doesn't
> > gconfd-2 have any other means of detecting database changes at run-time?
> 
> Not that I'm aware of.  Which is why it was added.  
> 
> Here's the discussion of adding the SIGHUP handling.
>   http://mail.gnome.org/pipermail/gconf-list/2004-June/msg00016.html
> Note that Havoc is quoted here stating that even sending SIGTERM should
> be okay for the way gconfd-2 is designed.

That thread also mentions problems, such as consecutive SIGHUP signals
sent by installation of multiple packages, as well as that an application
must be restarted, too, to see the new values actually.

> Debian is using this extensively with gconf using packages.  Here's a
> link to a discussion of changes to their debhelper scriptlet, dh_gconf
> http://lists.debian.org/debian-gtk-gnome/2004/06/msg00195.html
> 
> > If not, why doesn't gconftool-2 communicate with gconfd-2 upon
> > installing/removing schema files?
> 
> You'll have to get a reply from Mark or Havoc on that one.  As a guess,
> I'd think that gconftool-2 can be used by a normal user to install
> schemas or modify the configuration values for the user only.  In that
> situation, it has no business trying to convince all gconf's on the
> system to reload their cache.

Could be done for --makefile-[un]install-rule with a uid check,
couldn't it?

> This isn't the case on a package update where every gconf on the system
> needs to resync with the newly installed values.
> 
> -Toshio
>