Bugzilla – Bug 245550
gconftool-rebuild handling during system upgrade illogical
Last modified: 2007-09-12 14:27:02 UTC
While updating my system from 10.2 to Factory before all packages were moved to /usr, I noticed that gnome-power-manager started to misbehave randomly, caused by a corrupted gconf schema installation. Now I think I understand why this happened. The %pre script of the new gconf2 package moves etc/opt/gnome/gconf/gconf.xml.schemas to etc/gconf/gconf.xml.schemas. Until here, everything is fine. But then, in the %post script, it calls usr/bin/gconftool-rebuild, which rebuilds the database from scratch _without_ looking at the .schemas files in etc/opt/gnome/gconf/schemas. This means that gconf2 effectively deletes the schema installation of packages that it just moved. This is illogical. Possible fixes include: - Do not move etc/opt/gnome/gconf/gconf.xml.schemas to etc/gconf/gconf.xml.schemas. Instead, include compatibility etc/opt/gnome search paths in /etc/gconf/2/path. - Do not call gconftool-rebuild. - Re-add /etc/opt/gnome/gconf/schemas to the directories processed by gconftool-rebuild.
Not calling gconftool-rebuild is not a fix because the user can call it manually, which will have the same effect and is as bad as what currently happens.
Actually this bug should be titled "gconftool-rebuild breaks schemas of /opt/gnome packages", because that's what it does, no matter whether it is called by the user or by a package. I tend to believe that the last option (re-addition of /etc/opt/gnome/gconf/schemas) is the most reliable one. Strictly speaking we want to get rid of it, but I don't have a different idea that actually works. As outlined above, not calling gconftool-rebuild is not a fix and the first option (leaving etc/opt/gnome/gconf/gconf.xml.schemas untouched) has the problem that gconftool-rebuild will never clean it up because it doesn't "see" it. Another theoretical option is moving even the .schemas files from /etc/opt/gnome/gconf/schemas to /etc/gconf/schemas, but this contradicts packaging principles (situation on disk should be == situation in rpmdb).
Stanislav, can you take a look?
> Do not move etc/opt/gnome/gconf/gconf.xml.schemas to etc/gconf/gconf.xml.schemas. Instead, include compatibility etc/opt/gnome search paths in /etc/gconf/2/path. But standard old-style scriptlets install to the default location. On upgrade of any /opt/gnome package, we'll have two set of keys. > Do not call gconftool-rebuild. The best solution for future, but after upgrade protection from SLED10 expires (to never keep orphans). > Re-add /etc/opt/gnome/gconf/schemas to the directories processed by gconftool-rebuild. Yes, it seems to be acceptable. > Another theoretical option is moving even the .schemas files from /etc/opt/gnome/gconf/schemas to /etc/gconf/schemas, but this contradicts packaging principles (situation on disk should be == situation in rpmdb). No chance. It will either break fs<->rpmdb consistency (no symlink), or rpm will break it totally (symlink to /etc will confuse rpm)
> Re-add /etc/opt/gnome/gconf/schemas to the directories processed by gconftool-rebuild. This was done. Once /opt/gnome will be totally obsolete (after SLES12?), we could drop opt_gnome-compat. Even gconftool-rebuild itself will be obsolete in future (after SLES12 or SLES13) - new scriptlets never keep orphans. See long comments about it in gconf2.spec scriptlets.