I can't reproduce with Suse 9.1 and KDE 3.2.1. I don't have 9.2 for testing.
@  cloph: Any idea that might help?

I have the same problem as decribed under 1 with core01 package in yast2 on SuSE
9.3(standard install, all updates). Update used to work fine with all previous
developer version of 1.9.X.

I've tried again with ooo 2.0.2 rc2, and got exactly the same results when
trying to use Yast to either update or install from new.

Same here(Suse9.3, all updates): new attempt using rc2 shows the same as befor!
Packages were installed using yast package manager until package Core01. Yast
shows 100% of this package is installed, but doesn't go on to the next package
and doesn't respond at all. 
Since this prevents people from installing OOo, priority should be set to P1!
Hopefully one of the packager reads it and will fix it befor the release.

The message
"No theme index file in '/opt/kde3/share/icons/locolor'
If you really want to create an icon cache here, use --ignore-theme-index"

is informatinal only (no indicator of failure or error). You have a image-cache
where not index-theme file is. That doesn't really make sense and the default
behaviour of gtk-update-icon cache is to skip this directory with the above message.

I did not have time to check with yast yet, but since it works on the
commanline, I guess this is a bug in yast, not in rpm or in one of the packages.

I don't have any idea why it should hang on the core01 package either, since
that neither contains any scripts or triggers.

I only have SuSE 10.0 here (download version, and it is not installed currently)
so can anybody tell me whether the problem occurs there as well, or do I have to
get 9.X?

A couple of suggestions of how I could help:

1.  I can let you have the yast logs if they would be of use.  If you let me
know which ones - or simply the whole log directory - I can submit them as an
attachment or send them direct.

2.  Would it be worth asking on a relevant Suse list for confirmation or
otherwise? If so I will happily post a request for help.

Tested on 2.0.2 rc3.  Same results.

@cloph: what about removing 'locolor' from the list themes - just to check
whether the console output is really the problem ? Since locolor is KDE only it
is very unlikely to have a gtk icon cache anyway .. 

Im 99% sure that the gtk-update-icon-cache message is NOT related to the problem
of yast hanging up. 
If it was, then it would be a massive bug in yast. (Since 1st of all it should
not hang at all and 2ndly it would hide messages printed to stderr - that would
be a huge bug by itself)

Ans although locolor might be KDE-specific, there still may applications making
use of an icon-cache (that is not Gnome or GTK-only). 

And as the message from the reporter shows, there /is/ an icon-cache present. If
there would not be a cache, that directory would be skipped anyway.

Updating the icon-cache can take a while (but should not take 15 minutes)

I installed SuSE 10.0 again yesterday and now making a disk-image so I can plug
it in in future more easily. 

########################
Just remove the icon-theme.cache file from the locolor-directory and you won't
get the message.
You can take this as a test whether the gtk-update-icon-cache really is the
problem (I doubt that, but well - it is just software...)

I'd rather say it is the trigger-scripts that fail to run when called by yast.
But just skip the menu-integration package and see whether that causes yast to
hang as well.
If it doesn't hang, then there's something wrong with the menu-integration package.

I was able to reproduce (need to check again whether this was just coincidence).

The problem is not th gtk-update-cache or similar, but the trigger that is meant
to avoid concurrent access to the rpm database by checking whether "pgrep rpm"
returns a process-id and sleeps for 2 seconds if it does.

The problem is that one defunct rpm process is sitting around, causing the
install-script to go into an endless loop.

Solution: get the process-ID of the install-script and kill it. Now the
installation can continue.
(do 
ps ax|grep /tmp/install
look for a line with
"<number>  [...] /bin/sh /tmp/install.<another_number>"
then run "kill <number>")

tried again with same result.

when installing with yast, it for some reason creates a defunct rpm process that
leads to the loop in the trigger's install-script.

Not caused by the modifications to update the icon-cache. (happens with 2.0.1
packages as well).

Honestly I still wonder why people use yast to install rpms (it is so slow and
cumbersome to setup for non-installation media - it cannot even update the
directory itself, etc).. but anyway, here are the steps to reproduce on SuSE
10.0 (download-edition) based on a gnome-system:

#########################
0) copy the installation-files flat to a directory (Yast doesn't search in 
   subdirectories, so move the desktop-integration package to the same dir as 
   the other ones)
1) Run yast from the "system"-menu (supply root-password)
2) In the "Software" category choose "change installation source" (not sure 
   about the english label, but the badly translated german one is 
   "Installationsquelle wechseln")
3) Choose to add a local directory from the "Add" button and point to the path 
   with the RPMs created in step 0) (note that the entry-field doesn't support 
   "~" to specify the home-directory)
4) Leave the installation-Sources setup and switch to "Install or Deinstall 
   Software" ("Software installieren oder löschen")
5) Since the package-selection window doesn't allow multi-selection, search for
   "openoffice.org" (search only in package-name, not in description) then 
   choose to install all packages from the current selection from the  
   package-window's context-menu ("Alle in dieser Liste → Installieren")
6) Deselect the desktop-integraton packages (you may want to search for
   "openoffice.org*menus" with wildcard-match enabled)
7) Choose the button "Apply" from the lower right corner.

Yast will now install OOo (without the desktop-integration package which we will
install in a second step) and run some Update-scripts (useless and not needed
for OOo, but run nevertheless)

8) After the installation of the OOo packages is finished, choose to install 
   additional packages and verify in a terminal that you still have a clean
   environment (no defunct rpm-processes)
9) Choose to install the suse-menus package and click "apply"

The progress bar will reach 100% and then will stall. When checking in the
terminal, you'll notice a defunct rpm process.

10) Kill the install-script run by the trigger to allow the installation to
complete.

Since the trigger is not run, you'll have to create the symlink in /etc (and run
update-desktop-database) manually. Or better: Uninstall the menu-package and
install from commandline (where no problem occurs at all)

I tried rc4 on Suse9.3. Problem is still there. Yast freezes on installing
package core01 when trying to update from previous version.

@cloph: Yast kann sicherlich verbessert werden, aber bezogen auf Geschwindigkeit
ist immernoch OOo/SO (Negativ)Beispiel Nr.1! - UND: trotzdem gibt es immernoch
Leute die es verwenden :-)! - Dem hat die Entwicklung der letzten Jahre auch
nicht wirklich entgegengewirkt. Aber wenn die Prioritäten auch auf
Pinselfunktionen liegen und nicht wirklichen Einschränkungen ... Naja.

@obr: issue 61569 is about problems of a missing pgrep on a RedHat based distro.
So when the trigger-script gets a rework (which is necessary I guess) these two
shall both be taken into account, thus I set it to the depends on field.

Issue 88334 finally allows us to abandon the RPM database query and thus the
check for a running rpm in the trigger script.

RPM database check has been removed in CWS native147.

To verify, make sure you have a RPM version 4 and run 

rpm -qp --triggers <menus-package>

This should not gives any instances of 'pgrep rpm' any more.

OF: Looks good for me in cws native 147.

OF: Looks good for me in OOO300_m9.