GConf --makefile-uninstall-rule is incompatible with packaging systems

[Stanislav Brabec <sbrabec suse cz>]

Hallo.

I want to discuss a design problem of GConf --makefile-uninstall-rule.

I have been searching for the reason, why GConf database contains
obsolete keys after "correct" package update. I found that it is a
concept problem, which affects many packaging systems:

GConf expects following update process:
- --makefile-uninstall-rule for old schemas
- perform files update
- --makefile-install-rule for new schemas

Packaging systems do (with a good reason):
- preinstall of the new package
- install new files 
- postinstall of the new package (--makefile-install-rule for new schemas)
- preuninstall for the old package (too late for --makefile-uninstall-rule)
- uninstall obsolete old files
- postuninstall for old package
- posttrans for new package (RPM 4.4 only)

We need to do correctly following actions:
- Package was renamed.
- Package was splitted.
- Package was removed.
- Schemas file was moved to another package.
- Schemas file was renamed.
- Schemas file was removed.
- Two schemas files were merged.
- Two schemas files were splitted.
- GConf key moved from one schemas file to another in the same package.
- GConf key moved from one schemas file to another in different package.
- GConf key was deleted, schemas file remains.

There is no scriptlet for proper calling --makefile-uninstall-rule:
- %pre scriptlet of the new package does not have the list of schemas
included in the old version actually installed.
- %post, %preun: It's too late, some schemas were replaced.
- %postun: Even later. Not replaced rest was removed.
- Any combined method I can imagine can fail, too.


Thinking about it, it can be fixed by following ways:

1. Enhance packaging system:

For example, RPM can implement preuntrans scriptlet started from the old
package at the beginning of the update process.

2. Trace all old changes in schemas forever to be able to uninstall any
old version. Very ugly. Nightmare for packagers.

3. Rebuild GConf database from scratch after uninstallation of any
package. Relatively slow.

4. Enhance GConf:

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

http://bugzilla.gnome.org/show_bug.cgi?id=306924


Note:

This problem affects not only GConf, but also, for example install-info
and other scriptlets. But because GConf database is more complex,
problems caused by this incompatibility are real, not only theoretical.

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SuSE CR, s. r. o.                             e-mail: sbrabec suse cz
Drahobejlova 27                               tel: +420 296 542 382
190 00 Praha 9                                fax: +420 296 542 374
Czech Republic                                http://www.suse.cz/