Some relevant information for people using G:F. If you're seeing some weird stuff about gconf in the next few days, ping me.
----- Forwarded message from Vincent Untz firstname.lastname@example.org -----
Date: Thu, 26 Feb 2009 23:24:54 +0100 From: Vincent Untz email@example.com To: firstname.lastname@example.org, Michael Meeks email@example.com Subject: Re: [opensuse-factory] gconftool-2 makes factory update slow Mail-Followup-To: firstname.lastname@example.org, Michael Meeks email@example.com
Le jeudi 26 février 2009, à 02:35 +0100, Vincent Untz a écrit :
Le lundi 23 février 2009, à 22:01 +0100, Markus Koßmann a écrit :
Just updating factory I noticed that many gnome applications need a lot of time for running several instances of /usr/bin/gconftool-2 with --makefile- install-rule or --makefile-uninstall-rule arguments. in their install script. Compiz installation comsumed over 5 minutes for doing that Is this expected ?
This is certainly not expected. I think it's because of this change in gconf2:
Use "merged" for schema-install-source, for better performance.
After some discussion with Michael, and thanks to his input, I made some changes to the gconf2 package which should solve the issue in most cases:
+ we call gconftool-2 --makefile-install-rule only once per package using gconf now, instead of multiple times. This should improve things significantly for some packages. (we still have to call gconftool-2 --makefile-uninstall-rule too)
+ if the schema file hasn't changed between the old and the new package, we just skip this test. And since schema files don't change that often, this is a huge win.
I just put the updated gconf2 package in GNOME:Factory, so it'd be great to have people test GNOME:Factory to make sure it doesn't break anything. I'm a bit hesitant to directly push it to openSUSE:Factory since it can break stuff badly if I made a small mistake ;-) But we'll push it at some point.
Note that to really experience the improvement, you'll need to update to GNOME packages compiled with this new gconf. And then, on the following updates, it will be much faster. (the first update is still somewhat slow because the package you currently have has the old %preun script which is not optimal)