I wonder how many HUP signals you would like to send to running gconfd-2 instances when you register 20 schemas from control-center or libgnomeui for example in a for-loop.

I think it's up to the packager to do this, but it would be good to have a kill -HUP to running gconfd-2 processes in the program's Makefile if GCONF_DISABLE_MAKEFILE_SCHEMAS_INSTALL or whatever the var is called isn't set on make install.

On Archlinux we have been sending this -HUP signal to running gconfd-2 processes for a year or so now, which works quite good. The same applies to running bonobo-activation-servers, after installing epiphany for example, we have to -HUP that thing also.

I think, that gconftool-2 should support --reload or --hup. Just now, it will do only killall -HUP, but in future, we may have remote backends and this way (with proper backend API call) will be transparent to users and programmers.

Man page and --help should explain, that --makefile-install-rule needs --reload to activate changes.

Sending several HUP signals isn't a problem, as the signal is handled asynchronously, in the main loop - IIRC it runs every 30s.

*** Bug 156057 has been marked as a duplicate of this bug. ***

Btw, bug 151334 is about the same problem and it's marked as fixed by Mark :)

Hmm, wonder what bug I *actually* had fixed when I marked bug #151334 as fixed ? :-)

and I wonder why an older bug can be a *duplicate* of a newer report.

@mark can you change the state of #151334 to obsolete if it is not yet fixed or also close this bug, if it is fixed :)

Created attachment 99150 [details] [review]
call killall when installing/uninstalling schemas

I've attached a trivial fix for this bug. It requires killall on the system (ie it won't work on Solaris) but we've been using it since 2005 in Mandriva Linux without any issue.

I can improve it to detect the correct executable to use at configure time, if people want to merge it.

Ok, so basically, the concept of --makefile-install-rule is only useful in a jhbuild type scenario. Currently, it has two purposes:

1) Validate the schema
2) Contact the running gconfd and tell it about the new schema

Now in reality, most operating system vendors have bought into this concept of "packages" which are run as root, and step 2) should be a no-op because users log in as uid 500 or whatever.

The way I suggest this work is that vendors who are using package systems ensure that after all schemas from a package run are installed, the running gconfd is signaled exactly once, and it immediately reloads all schemas atomically.

So concrete actions:

1) Change SIGHUP to reload immediately, rather than after 30 seconds
2) Remove usage of SIGHUP from individual packages
3) Add a single post-transaction SIGHUP from package system to all running gconfds

I'll do the patch for gconfd; we may need a configure option for --enable-delayed-sighup or something for OS vendors who are still shipping individual packages which send SIGHUP.

3) Well, at least rpm has no "single post-transaction script" concept yet: http://www.rpm.org/wiki/Problems/Scriptlets#Databaserebuild

Colin, I might be misreading what you're saying, but just to be clear

--makefile-install-rule is how schemas are installed.  It's not an optional command. It's what reads the schemas from /etc/gconf/schemas (or wherever the distro stuff thems) and writes them into the gconf database where gconfd will use them.

The problem with the killall type command is it's a little hacky.  gconfd processes never register with the system, so instead the idea is to blindly kill all processes with the name gconfd-2 or whatever

A few better approaches:

1) emit a dbus signal on the system bus that the gconfd processes listen for and packaging systems emit (maybe packagekit already has one?)

2) add gio monitors to the read-only gconf sources and automatically reload them when they change.

Stanislav, rpm does have a %posttrans scriptlet.  It's been historically ignored as a bad idea, but it's gained usage recently.

%posttrans runs command defined in particular spec file at the end of the transaction.

As you have no way to detect last package in the transaction thas has gconf schemas to install/uninstall, you have no way to run it just once.

Things are even worse: You have %posttrans that can be used for makefile-install-rule but there is no scriptlet that can be used for makefile-uninstall-rule because %preuntrans does not exist (the only "un" scripts are %preun and %postun are both called too late to be usable - old files are already overwritten by the new context.


The first problem can be worked around by an enforcing a policy of calling a special script after each rpm installation. (Such work around is not acceptable.)

The second problem can be worked around by a co-ordined combination of three scripts that temporarily keeps overwritten old instances. This is a way used in openSUSE/Novell:

preinstall scriptlet (using /bin/sh):
mkdir -p usr/share/gconf/schemas/outdated
if test -f usr/share/gconf/schemas/example.schemas ; then
    ln -f usr/share/gconf/schemas/example.schemas usr/share/gconf/schemas
fi

preuninstall scriptlet (using /bin/sh):
if test "$1" == "0"; then
    if test -x usr/bin/gconftool-2 ; then
        export GCONF_CONFIG_SOURCE=`usr/bin/gconftool-2 --get-default-source`
    fi
    if test -x usr/bin/gconftool-2 ; then
        if test -f usr/share/gconf/schemas/outdated/example.schemas ; then
            usr/bin/gconftool-2 --makefile-uninstall-rule usr/share/gconf/schemas/outdated/example.schemas >/dev/null
        elif test -f usr/share/gconf/schemas/example.schemas ; then
            usr/bin/gconftool-2 --makefile-uninstall-rule usr/share/gconf/schemas/example.schemas >/dev/null
        fi
    fi
    rm -f usr/share/gconf/schemas/outdated/example.schemas
    rmdir usr/share/gconf/schemas/outdated 2>/dev/null || true
fi

posttrans scriptlet (using /bin/sh):
export GCONF_CONFIG_SOURCE=`usr/bin/gconftool-2 --get-default-source`
INSTALL_SCHEMA_FILES=
UNINSTALL_SCHEMA_FILES=
if test -f usr/share/gconf/schemas/outdated/example.schemas; then
    cmp --quiet usr/share/gconf/schemas/outdated/example.schemas usr/share/gconf/schemas/example.schemas
    if test $? != 0; then
        UNINSTALL_SCHEMA_FILES="$UNINSTALL_SCHEMA_FILES usr/share/gconf/schemas/outdated/example.schemas"
        INSTALL_SCHEMA_FILES="$INSTALL_SCHEMA_FILES usr/share/gconf/schemas/example.schemas"
    else
        rm -f usr/share/gconf/schemas/outdated/example.schemas
    fi
else
  INSTALL_SCHEMA_FILES="$INSTALL_SCHEMA_FILES usr/share/gconf/schemas/example.schemas"
fi
if test "x$UNINSTALL_SCHEMA_FILES" != "x"; then
    usr/bin/gconftool-2 --makefile-uninstall-rule $UNINSTALL_SCHEMA_FILES >/dev/null
    rm -f $UNINSTALL_SCHEMA_FILES
fi
if test "x$INSTALL_SCHEMA_FILES" != "x"; then
    usr/bin/gconftool-2 --makefile-install-rule $INSTALL_SCHEMA_FILES >/dev/null
fi
rmdir usr/share/gconf/schemas/outdated 2>/dev/null || true

On bug 558490 there is discussion about making the schema source be completely separate from everything else (and novell already does that?).

If we did that, then %posttrans could just reinstall the entire schema database, swivel it in place, and then remove the old database.  It might be too slow in practice to do after every transaction, though.  If it is, then I think something like comment 12 is maybe the most viable option

An alternative, would be to make gconf read and use /etc/gconf/schemas directly, instead of having the install step at all.

Then again, maybe the right answer is "leave gconf alone since dconf is on the way"

Yes, Novell uses:

gconf.xml.defaults: Defaults defined by sysadmin e. g. by gconf-editor.

gconf.xml.vendor: Vendor defaults defined by vendor branding packages. See also bug 522055.

gconf.xml.schemas: Package defaults defined in schemas files and nothing else.

This design ensures that sysadmin defaults are never overwritten and that the distro branding can be delivered independently on the package itself.


%posttrans alone cannot remove the old database correctly during the upgrade - list of keys in the old schemas file is not available (it's already overwritten by the new instance), and simple scriptlets keep orphans if the new schemas file has less keys than the old one. But this is a problem of rpm design and not fault of gconf.

right, you can't clean up the schema database piecemeal without keeping a list around, but you can start with a fresh schema database and rebuild it from scratch.  Then you don't need to prune it, since it's clean from the get go.  That's what paragraph 2 of comment 13 was suggesting.

Created attachment 160738 [details]
gconftool-rebuild

Yes, it is a posibility, but it may take longer than makefile-install-rule.

SUSE distributes gconftool-rebuild script for this purpose (see the attachment).

It runs much faster with new gconf versions (seconds in comparison to minutes several years ago).

You still have to run it many times with rpm - you cannot run it just once when transaction ends.

(In reply to comment #16)

> Yes, it is a posibility, but it may take longer than makefile-install-rule.
right

> SUSE distributes gconftool-rebuild script for this purpose (see the
> attachment).
Yea this is exactly the sort of thing I was thinking of.

> You still have to run it many times with rpm - you cannot run it just once when
> transaction ends.
why?

>> You still have to run it many times with rpm - you cannot run it just once when
>> transaction ends.
>why?

Adding gconftool-rebuild to %posttrans and %postuntrans of each package with schemas will generate many calls of gconftool-rebuild at the end of the transaction. rpm provides no way to detect that it was already called in the context of the current transaction (well, meabe tricky comparing of time stamps of the /etc/gconf/schemas and keys in the database can help here).

Solutions:

- Mandriva has a bit hacky patch that allows to call some scripts when rpm exits and stamp file exists.

- I have proposed new rpm feature: One time triggers triggered by virtual symbols. It may look as follows:

In package that contains schemas:
Provides: run_gconftool_rebuild

In gconf package:
%triggerposttrans run_gconftool_rebuild
gconftool-rebuild

Maybe it can be called %triggertransonce (it should be called only once for all packages and both %triggerposttrans and %triggerposuntrans).

I guess that this feature is not yet implemented. Please consult it with your rpm experts.

Ah, I see what you mean.

Timestamp checking should work fine, though, yes?  It's how we manage other things like this (gtk-update-icon-cache for instance).

(In reply to comment #19)
> Timestamp checking should work fine, though, yes?  It's how we manage other
> things like this (gtk-update-icon-cache for instance).

This is something that doesn’t work at all with gtk-update-icon-cache - admittedly, it would work better with GConf schemas since they are all in the same directory.

For the record, in Debian we already have a script to register all schemas at once, and we use directory-based triggers to run the registration only once.

*** Bug 664921 has been marked as a duplicate of this bug. ***

GConf has been deprecated since 2011.

GConf is not under active development anymore. Its codebase has been archived:
https://gitlab.gnome.org/Archive/gconf/commits/master

dconf and gsettings are its successors. See https://developer.gnome.org/gio/stable/ch34.html and https://developer.gnome.org/GSettings/ for porting info.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Feel free to open a task in GNOME Gitlab if the issue described in this task still applies to a recent + supported version of dconf/gsettings. Thanks!