There is a problem of incompatible design of current packaging systems (at least
RPM and portage, probably deb, too) and GConf uninstall rules.

GConf expects "remove old, then install new", packaging systems do "install new,
then remove residues of old".

It is not possible to uninstall rules correctly in all possible situations
(schemas file deleted, schemas file moved to another package, schemas file
splitted, keys was deleted key was moved to another schemas file) without
permanently raising list of needed changes.

Generally it causes only raising number of orphan GConf entries, but in
particular situations (changes in thumbnailers) it can cause bad function of GNOME.

There are two possible solutions - adopt packaging systems to be able to work
with current packaging systems (for RPM it means implementation of %preuntrans
scriptlet) or adopt GConf to be able to use current scriptlets %post and %preun.

Third solution is creating alternative key database, which is independent on RPM
and GConf and updates keys properly. This is an ugly work-around.

I spent a lot of time trying to fix. But it's seems to be impossible without
maintaining outdated keylists forever.


The problem is, that packaging systems first installs new files, then removes
old ones. It means, that --makefile-uninstall-rule in %preun is called after old
files are overwritten, but it is designed to be called before overwritting of
old files. But for example RPM does not have such feature.

Note that packaging system solution will have principial problem with keys
outage during update. It means, that application started during update will not
work an may even introduce bad defaults to user GConf database.


What needs to be changed in GConf to be compatible with current packaging systems:

- Add serial to schemas file name. The serial has to be changed whenever key
list in schemas file changes.

- Add serial attribute to schemas file (or add serial to owner attribute).

- Improve --makefile-uninstall-rule to uninstall only keys owned by proper owner
(or add --makefile-uninstall-unowned-rule).

- Optionally add ownership check to --makefile-install-rule - it should issue
warning, when overwriting key with different owner. It can be OK if package is
renamed, splitted, but generally it can mean problems.

- Optionally implement --flush resp. --lock/--unlock option, which will signal
all running gconf daemons to forget and re-read all cached values from selected
source resp. lock the database and delay user daemons until database is unlocked.