Bugzilla – Bug 48114
orphan gconf2 files after uninstallation/update
Last modified: 2007-08-09 17:08:23 UTC
Our SuSEconfig.gconf2 implements only --makefile-install-rule, but not --makefile-uninstall-rule. It causes orphan/outdated gconf2 items in installed database after package update or remove. Fix will require %preun for all packages complementary to %post and implementing run-gconf2-schema-uninstallation.
This bug also affects package galeon, bug Bugzilla rejects to accept this package name.
We have a temporary solution in PLUS, STABLE and 9.0 (not YOU) as side of bug 48078 fix (clean-up is done during gconf2 update). Clean fix is still needed.
It seems that it is not possible to solve it correctly using current version of gconftool and RPM. Proposed solution: Install schemas in %post. Don't deinstall it at all (all possible ways inside RPM are dangerous and can fail in particular cases). Add script for gconf database rebuild from scratch. Add one time script to run this rebuild after product upgrade.
For system update it's already solved (bug 51196). For package uninstallation, there is gconftool-rebuild. There is a chance to collect key lists and purge via script, which can be implemented in future, if gconf itself will not solve it. Decreasing to minor.
Packaging problem then
No, it's a problem of incompatible design of RPM and GConf. GConf expects "remove old, then install new", RPM does "install new, then remove residues of old". Adding RPM expert to Cc:. Please re-assign bug to somebody who can discuss this and implement it. There are two possible solutions - adopt RPM to be able to do it (it means implementing 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 updated keys properly. Fourth solution is rebuilding GConf database from scratch after each update (I wrote a script gconftool-rebuild to do it). 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 RPM does not have such feature. I guess it's not yet reported upstream. What needs to be changed in RPM to be compatible with current GConf: - Update to latest RPM, which implements %posttrans - Implement %preuntrans scriptlet as a counterpart of %posttrans Note that this solution will have principial problem with service outage during update. What needs to be changed in GConf to be compatible with current RPM: - 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.
Reported upstream: http://bugzilla.gnome.org/show_bug.cgi?id=306924
Due to the proposal from Andreas Jaeger, open bugs for the versions 8.2 and 9.0 will be closed as the probability that these bugs are already fixed in the current realease is very high. If, however, one of these problems are still residing in the current release (10.0 RC4 or greater), the component should be changed accordingly and the bug should be reopened with a useful comment and/or information helping to actually solve the problem. In the same step, these reopened bugs should be assigned. With kindly regards, the BNC-Screening-Team
Still not properly fixed, only worked around in distribution upgrade. In one particular situation, this work-around causes real problems - if package providing a thumbnailer is removed, there is no way to remove associated GConf keys.
There has been no activity for more than 3 month. I'm closing this bug as WONTFIX. If you feel this is inappropriate and the bug should remain open, or you have new information which may lead to an actual resolution, please reopen the bug and add the new status.
Re-opening. This needs fixing at some point.
Resolving later.
Reopening. It seems, that using combination of %pre, %preun and %posttrans can do the stuff cleanly.
I believe that the problem is just now fixed correctly by gconf2 /etc/rpm/macros.gconf2.