On Sun, Oct 23, 2011 at 09:52:56PM +0800, Aron Xu wrote: > We tried to workaround it in Fcitx by recommending GTK2 IM Module in > the GTK3 package, and do the inverse in the GTK2 package. In this > case, users are very probably getting both IM Modules installed at the > same time, so they can avoid weird misbehavior of installing only one > of the two.
Is having dependency loop OK for recommend? I think this is bad idea. See "the circular dependency loop" in recent policy: http://www.debian.org/doc/debian-policy/ch-relationships.html If there is a circular dependency among packages being installed or removed, installation or removal order honoring the dependency order is impossible, requiring the dependency loop be broken at some point and the dependency requirements violated for at least one package. Packages involved in circular dependencies may not be able to rely on their dependencies being configured before they themselves are configured, depending on which side of the break of the circular dependency loop they happen to be on. If one of the packages in the loop has no postinst script, then the cycle will be broken at that package; this ensures that all postinst scripts are run with their dependencies properly configured if this is possible. Otherwise the breaking point is arbitrary. Packages should therefore avoid circular dependencies where possible, particularly if they have postinst scripts. > To answer your question ultimately, we need to have two things fixed in GTK3: > 1.Add a GTK3_IM_MODULE variable. This needs buy-in from upstream. Do they support it? Does it works older packages with few updated packages or do we need to recompile many packages? > 2.Better fallback handling when GTK_IM_MODULE is set but the the > specified IM Module does not work or isn't present. It is expected to > fallback to XIM when this happens, but currently the fallback does not > work at all. True. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
