Bug 548605

I've done another update from 11.1 to 11.2-final: same performace problems with some gnome-related packages:

     rpm -qa --qf '%{INSTALLTIME} %{NAME} %{VERSION}\n' | sort -nr | awk '{print l-$1,$0;l=$1}' | sort -nr | less

shows the same "slow" packages:

   256  compiz-0.7.8
   240  compiz-fusion-plugins-main-0.7.8
   212  gnucash-2.2.9
   205  libgnome-2.28.0
   178  gnome-games-2.28.0
   142  evolution-2.28.0
   125  gnome-applets-2.28.0
   109  gnome-panel-2.28.0
    92  gnome-vfs2-2.24.1
    92  gnome-settings-daemon-2.28.0
    91  pullin-msttf-fonts-11.2
    83  gnome-utils-2.28.0
    81  evince-2.28.0
    80  timezone-java-2009p
    79  tvbrowser-2.7.2
    75  kernel-xen-2.6.31.5
    59  kernel-default-2.6.31.5


the compiz preuninstall script calls gconftool-2 34 times, while there
are ~250 calls alltogether (so  256 secs / 33 * 249 ~= 1931 secs just for gconftool-2 !)

	harald > rpm -q compiz  --scripts | grep -A2 ' if test -f usr/share/gconf/' | grep -c usr/bin/gconftool-2 
	33

	harald > rpm -qa  --scripts | grep -A2 ' if test -f usr/share/gconf/' | grep -c usr/bin/gconftool-2 
	249

which matches

	harald > ls /usr/share/gconf/schemas/*.schemas | wc
	    248     248   12515


gconftool-2  sucks ?!?

Isn't this just the non-delayed suseconfig problem?

gconftool-2 sucks especially if it is executed for each gnome package being installed. openSUSE avoids this in CD installation (in YaST, more precisely) by setting YAST_IS_RUNNING env. variable, and packages are hacked to avoid runing suseconfig (which in turn runs gconftool). Then YaST executes suseconfig only once, at the end of installation.

We avoid doing this in zypper, because it is hack that the package management software needs to know about. Instead we encourage proper solution on the rpm level: see bug 365649, and https://features.opensuse.org/305472. (Although we could probably do this for dist-upgrade, until the feature is done).

In the meantime, use the workaround described at http://en.opensuse.org/Upgrade/Supported#Known_Issues (the one with YAST_IS_RUNNING) if needed (and vote for the feature in fate :O).

@zypp guys: anything on your mind we should do about this?

*** This bug has been marked as a duplicate of bug 365649 ***

(In reply to comment #2)
> Isn't this just the non-delayed suseconfig problem?
> 
> gconftool-2 sucks especially if it is executed for each gnome package being
> installed. openSUSE avoids this in CD installation (in YaST, more precisely) by
> setting YAST_IS_RUNNING env. variable, and packages are hacked to avoid runing
> suseconfig (which in turn runs gconftool). Then YaST executes suseconfig only
> once, at the end of installation.

my update was started via boot from NET-CD and yast did the update (totally standard)!

YAST_IS_RUNNING is not evaluated at all in compiz scripts:
		
		rpm -q --scripts compiz | grep YAST_IS_RUNNING

"rpm -qa --scripts" shows YAST_IS_RUNNING being used for some SuSEconfig.fonts calls and other stuff, but I can't find any flagged calls to gconftool-2

am I missing something, or is that YAST_IS_RUNNING flag missing for gconftool-2 issues ?

> In the meantime, use the workaround described at
> http://en.opensuse.org/Upgrade/Supported#Known_Issues (the one with
> YAST_IS_RUNNING) if needed (and vote for the feature in fate :O).

thanks for this pointer, I'll keep it in mind for "zypper dup",
but in my case yast *was* running!

Sorry, i was under impression that you did 'zypper dup'.

(In reply to comment #3)
> "rpm -qa --scripts" shows YAST_IS_RUNNING being used for some SuSEconfig.fonts
> calls and other stuff, but I can't find any flagged calls to gconftool-2

It could be executed via suseconfig. But then i wonder why the YAST_IS_RUNNING hack did not work.

> am I missing something, or is that YAST_IS_RUNNING flag missing for gconftool-2
> issues ?

Perhaps, we need to ask the maintainers of the pacakges.

Stando, do you know something about this?

Yes, I seen this problem as well.

I guess it is caused by the migration to merged tree in /etc/gconf/schema-install-source.

Slow installation is a cost for fast use.

I guess that measurements were done by Michael and Vincent. Do you have any ideas for improvement?

Could following work?:

- Install to multi-XML database.

- And then merge tree just once at the end.

Well, implementation of such behavior is again limited by the current RPM: lack of one-time actions: http://www.rpm.org/wiki/Problems/Scriptlets#Databaserebuild

Well ... the real problem is the translations here; and merging them all one by one into the big, per-language, split out translation files.

The cost is proportional to the number of schemas, and can be substantially reduced if we merge lots of them at a time with a single gconftool-2 call.

So - some easy wins (last I looked) would be to eg. merge the umpteen, tiny, content-less schema files inside compiz into a single file ;-) prolly the same for gnome-games, and - if possible to merge several schemas at a time after the transaction (?).

guys, please take this bug then :O)

I'm going to mark this as dup of bug 546543, which is really the same bug.

*** This bug has been marked as a duplicate of bug 546543 ***