Bug 245550

Summary:	gconftool-rebuild handling during system upgrade illogical
Product:	[openSUSE] openSUSE 10.3	Reporter:	Andreas Hanke <andreas.hanke>
Component:	GNOME	Assignee:	Stanislav Brabec <sbrabec>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None
Version:	Alpha 1
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Andreas Hanke 2007-02-14 19:52:43 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.

Comment 1 Andreas Hanke 2007-02-14 19:55:23 UTC

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.

Comment 2 Andreas Hanke 2007-02-14 20:11:08 UTC

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).

Comment 3 JP Rosevear 2007-07-26 20:30:51 UTC

Stanislav, can you take a look?

Comment 4 Stanislav Brabec 2007-09-11 17:45:49 UTC

> 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)

Comment 5 Stanislav Brabec 2007-09-12 14:27:02 UTC

> 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.