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

Toshio Kuratomi toshio at tiki-lounge.com
Thu Oct 6 03:38:23 UTC 2005


On Thu, 2005-10-06 at 00:44 +0200, Michael Schwendt wrote:
> On Wed, 05 Oct 2005 23:59:16 +0200, Thorsten Leemhuis wrote:
> 
> > Am Mittwoch, den 05.10.2005, 23:34 +0200 schrieb Michael Schwendt:
> > > On Tue, 27 Sep 2005 20:18:37 -0400, Christoph Wickert wrote:
> > > 
> > > > Author: cwickert
> > > > 
> > > > Update of /cvs/extras/rpms/regexxer/devel
> > > 
> > > > %pre
> > > > if [ "$1" -gt 1 ]; then
> > > >     export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
> > > >     gconftool-2 --makefile-uninstall-rule \
> > > >       %{_sysconfdir}/gconf/schemas/%{name}.schemas >/dev/null || :
> > > >     killall -HUP gconfd-2 || :
> > > > fi
> > > > 
> > > > 
> > > > %post
> > > > export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
> > > > gconftool-2 --makefile-install-rule \
> > > >   %{_sysconfdir}/gconf/schemas/%{name}.schemas >/dev/null || :
> > > > killall -HUP gconfd-2 || :
> > > > 
> > > > 
> > > > %preun
> > > > if [ "$1" -eq 0 ]; then
> > > >     export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
> > > >     gconftool-2 --makefile-uninstall-rule \
> > > >       %{_sysconfdir}/gconf/schemas/%{name}.schemas > /dev/null || :
> > > >     killall -HUP gconfd-2 || :
> > > > fi
> > > 
> > > Ugh! The package ought not killall any process.
> > > That looks like something really ugly.
> > 
> > Well, for me it looks like something taken directly from
> > http://www.fedoraproject.org/wiki/ScriptletSnippets#head-ff64cd482595764f672082d5a3b83e1fc22962e8
> > 
> > I find it rather ugly, too. I mentioned that before long ago (you might
> > find it in the archives of this list). But nobody could find any real
> > issues with this approach iirc and it seems it even found its way into
> > the wiki. 
> 
> 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.  Otherwise, opening up a program that's just been
updated with a different schema could run into problems.  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.

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.

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

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20051005/7b4c2a63/attachment.sig>


More information about the fedora-extras-list mailing list