Description of problem: # repoquery -C -q --requires scim-lang-korean.x86_64 /usr/lib/gtk-2.0/immodules/im-scim-bridge.so /usr/lib64/gtk-2.0/immodules/im-scim-bridge.so scim-bridge-gtk scim-hangul Other scim-lang-XXX packages are similar. This is wrong: 1) File dependencies are *bad* from a depsolver standpoint 2) This overrides the administrator set multilb policy - if they set that they only want the 'best' arch, these will still get pulled in. 3) This makes the x86_64 Live image go over a CD size. I understand that there are situations where we could conceivably want both arches of something available to support packages, even if they aren't direct DSO deps. See bug 442047. But we don't do dependencies like this for other cases (PAM and NSS modules), and we certainly shouldn't override the administrator's policy. Version-Release number of selected component (if applicable): scim-1.4.7-21.fc9
This is really a hack to workaround an unfiled gtk immodule handling bug: if you are on a multilib box and have GTK_IM_MODULE set and run a gtk app for an arch without that immodule installed then the startup of the application is "awkward". Qt handles this rather better just following back to XIM say. This hack has been in the distro for a while so it is a little late to bring up but I suppose we could disable it relunctantly now to save our multilib faces. :)
Though it would be nice to know how do we make scim-bridge-gtk multilib then? Add a fake scim-bridge-gtk-devel package?
Setting multlib_policy=all and adding scim-bridge-gtk to 'default' packages for those lang groups should do the trick if you want both arches.
Fixing in scim-1.4.7-23.fc9
> Setting multlib_policy=all and adding scim-bridge-gtk to 'default' packages for > those lang groups should do the trick if you want both arches. The first part of this suggestion doesn't solve the problem of making it multilib in the repo? This is only a configuration option on the client to make it install both archs of a package instead of only the 'best'. This means nothing in the default install ensures that 32bit apps work with SCIM on a 64bit desktop?
(In reply to comment #5) > The first part of this suggestion doesn't solve the problem of making it > multilib in the repo? The packages will be in the repo, just as they were before. > This means nothing in the default install ensures that 32bit apps work with SCIM > on a 64bit desktop? ... and? This has been broken for QT4/KDE4 for the entirety of F9 (packages weren't even in the repo!) and no one noticed. To quote a different mail on the subject: Let's create some classes of 32-bit users: 1) those that use binary-only mozilla/firefox plugins 2) those that use binary-only QT3/QT4 apps and want to use an input method 3) those that use binary-only apps and get user or host information via LDAP, a database, or mDNS 4) those that use binary-only apps and want to authenticate via SMB, MySQL, Kerberos, etc. 5) those that use binary-only GTK apps and want to use an input method I see no reason why we should go to strange hacks to support #5 out of the box when we don't support *any* of #1-#4 out of the box.
Verified.