Bug 546543

Moving it to critical as it slows down the install/ upgrade heavily.

This report might be a duplicate of bug 476292.

Before anyone closes it as dupe of that, "You are not authorized to access bug #476292."

slow down is not data loss

@#3 - the bug is all about http://lists.opensuse.org/opensuse-factory/2009-02/msg00334.html

Might it be useful to tweak while an upgrade of an earlier version to replace the usr/bin/gconftool-2 binary by a dummy which does nothing while the upgrade is performed?

After the upgrade we might install the 11.2 gconftool-2 binary again.

@Michael: You might have a better idea how to deal with this situation of existing 11.1 scripts which are executed at the update of many gnome packages.

Nope, the only way I know is to look at the source of gconftool and make it faster. That's what we did with ldconfig.

duplication of bug 476292.

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

Bug#476292 is not open to public so reopen....

There is no reference in the gconf2 package change log I've installed with openSUSE 11.2 RC 2 today (2.28.0-2.5) to this bug ID.

Got this issue silently fixed?

This is a critical issue.  We have openSUSE 11.2 released and updates are very slow cause of this gconftool-2 issue.

Looks like the fix was not merged in time.

No reference to this bug ID nor to 476292 in the gconf2 package change log.

Lars,

 Now in 11.2 the gconf2 has already been changed for optimized by Vincent.

In the changelog you'll find below lines.

Thu Feb 26 19:57:17 CET 2009 - vuntz@novell.com

- Update macros.gconf2 to have faster package upgrades:
  + do only one gconftool-2 --makefile-install-rule for all the
    schemas files, instead of multiple calls
  + compare the old schema with the new one and if they are not
    different, skip the --makefile-uninstall-rule and
    --makefile-install-rule for it
  + note: this adds a dependency on diffutils for all packages
    shipping gconf schemas


http://lists.opensuse.org/opensuse-factory/2009-02/msg00334.html
And from the link you can find

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

 And the bug 476292 is for SLE11, the gconf is 2.24, theren't update the file, so now I've just changed the macros like Vincents.

 So I thought this bug should be changed to fixed.

->Fixed.

Feel free to contact me if any issue.

Please reference bugzilla IDs in the package change log as the majority of packages do.

Take the kernel or Samba packages as an example.

Without bug references our customers and users do not have a chance to check if a particular bugfix got merged.

Sorry about it, we should always add the bug number for bug fix, thanks.

Still rather slow while updating 11.2 to 11.3.

This bug is back with a vengence in 11.3.

    I updated 11.2 -> 11.3 and then updated the remaining packages from within yast. After the yast updates, compiz was dead, so I went to remove it and start over trying with either J's packages in XGL or Dominiques' in compiz. No big deal, I've done this 50 times before, but this time:

rpm -e $(rpm -qa | grep "compiz\|fusion\|emerald") python-ccm simple-ccsm

took so long to complete, I canceled the process at 10 minutes to check whether it was stuck. In ten minutes time, it had only removed 6 out of the 13 compiz packages that needed to be removed. Checking further, the problem was gconftool-2 stuck at the top of top. I don't know what the heck it was doing, but it was sitting there eating between 30% and 50% of the cpu the entire time I was trying to rpm -e compiz with the cli above.

    Why is gconftool-2 running when removing compiz rpms anyway? Compiz removal should take no more than 30 seconds. As I've said above, I've probably done it 50 times in the past 3 years. In 11.3 it took over 20 minutes to remove the 13 packages that make up my compiz install:

08:15 zephyr:/home/backup/rpms/suse11.3> rpm -qa | grep "compiz\|fusion\|emerald" | sort -u
compiz-0.8.6-49.1.i586
compiz-branding-SLE-0.8.6-49.1.i586
compiz-branding-openSUSE-0.8.6-49.1.i586
compiz-branding-upstream-0.8.6-49.1.i586
compiz-emerald-0.8.6-13.1.i586
compiz-gnome-0.8.6-49.1.i586
compiz-plugins-extra-0.8.6-5.1.i586
compiz-plugins-main-0.8.6-7.1.i586
compiz-plugins-unsupported-0.8.4-1.1.i586
compizconfig-settings-manager-0.8.4-16.1.noarch
fusion-icon-0.0.1_080201-8.1.i586
libcompizconfig-0.8.4-3.1.i586
python-compizconfig-0.8.4-9.1.i586

     It would appear that a regression has occurred...  Let me know if I can provide any additional information and I'll be happy to. Thanks.

*** Bug 637228 has been marked as a duplicate of this bug. ***

And it's still the same with openSUSE 11.4 RC 1.

@Coolo: Please add openSUSE 11.4 as "Platform" too.  It's currently available as "Product" only.

(In reply to comment #20)
> And it's still the same with openSUSE 11.4 RC 1.

What is the version you're upgrading from?
For which packages is it extremely slow? (all packages with gconf schemas, or only a few)
How slow is "slow"?

I've performed an upgrade from an up to date oS 11.3 to 11.4 RC 1.

It's slow for all packages calling gconftool-2 in the scripts section.

I'm using zypper and therefore I see the progress and then it stops for 5, 10 or even more seconds.  Enough time to call top in a different shell and to call ps and identify gconftool-2 forked from rpm.

Is the hardware a Pentium 1 110 MHz?  No, it's a dual core CPU running at 2.2 GHz and with 4 GB of main memory.

As I'm performing the install from an ISO image from an external disk attached to the same computer I'm sure the system isn't waiting for network IO.

Ah, right: since nearly all schemas are different between 11.3 and 11.4, this is kind of expected. What I fixed is the case where you install a maintenance update; this won't be slow in 99% of the cases since the schemas are the same.

FWIW, it's way too late to do anything about this for upgrades to 11.4. If someone takes a look, it might get fixed for upgrades from 11.4 to 11.4+1; it certainly won't be my priority, though... In all cases, upgrades from 11.4+1 to 11.4+2 likely won't be affect as much, since most apps will be using gsettings by then, and not gconf anymore.

I don't maintain bugzilla. you can file enhancements yourself

*** Bug 548605 has been marked as a duplicate of this bug. ***

Why not use triggers or some other mechanism to run gconftool-2 only *once* at the end of /all/ rpm installs rather than (at least) once per package?

(In reply to comment #26)
> Why not use triggers or some other mechanism to run gconftool-2 only *once* at
> the end of /all/ rpm installs rather than (at least) once per package?

Because we don't have a really good way to do this right now.

(FWIW, the upgrade to 12.1 will be a bit painful too, but since gconf is dying away, this should get better after that)

Based on last experiences and development: closing this bug.

GConf schemas are slowly dying out, most apps in 12.2 did move to gsettings by now.

And unless we get RPM triggers, there is anyway not much that could be changed (in order to ensure all goes well).