Description of problem: Starting any of "component programs", like for example 'oowriter', from openoffice.org-1.9.89-3 comes with the following warning: (soffice.bin:3750): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks", 'locate' shows only one "clearlooks". Namely /usr/lib64/gtk-2.0/2.4.0/engines/libclearlooks.so from gtk2-engines package. If that is what is serched for then 32-bit soffice.bin cannot use 64-bit libraries but a dependency on gtk2-engines.i386 does not seem to be present. That warning may be not so benign as I observed right after that a progress bar on OO splash to stop and 'oowriter' stuck and not starting. OTOH this does not seem to be easy to reproduce and it may be unrelated. Version-Release number of selected component (if applicable): openoffice.org-core-1.9.89-3 How reproducible: On every program startup.
I think adding a Requires: libbluecurve.so should do the right thing
I do not know package relationships to that level, and what this library really provides, but "libbluecurve.so" sounds awfully specific. Is that really a good idea? What if "artwork" will change for any reasons? If "Unable to locate theme engine" is really only a warning, and there are no good ways to avoid it, I think that I prefer a warning over a spurious dependency.
It's what the 1.1.X rpm does. From rh#153129# it seems the best way to force an i386 dependancy on a package that is not directly linked to by the app is to require directly a .so from that package. 1.1.X picked libbluecurve.so which will pull in the gtk-engines from i386 so hopefully the same will work for 2.0
Why then not simply 'Requires: gtk-engines' instead of forcing that in a roundabout way which has a potential of failing in the future?
Because Requires: gtk-engines is useless for x86_64, it would be matched against the 64bit gtk-engines. Which is what happened in rh#153129#
Hopefully good in 1.9.89-5