On Sun, Oct 23, 2011 at 22:41, Osamu Aoki <os...@debian.org> wrote: > 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. > >
You can remove anything that is "Recommend"ed by other packages and don't need to worry about broken dependencies. APT just _install_ recommended packages, but they are surely _not_ dependencies so it won't hurt when removing any "Recommend"ed package. On the other side, the two IM Modules can be installed in any order, so we don't need to care about postinst scripts for them. Yes, I know doing this is not the ideal solution, it's a bit tricky and it *works*. I believe a working input method is better than nothing, so I recommend ibus to do this as well. When the following two things being resolved, we can come back to the *ideal* way. >> 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? > I haven't gotten in touch with GTK upstream nor Debian pkg-gnome, and I don't know about their work flow. I would like to see someone jump in here to help coordinate with GTK developers and us. This variable is something great to have. We can specify IM Module for GTK3 with it so we can ultimately solve the problem when GTK2/3 IM Modules aren't installed at the same time. During the years with GTK2, fallback mechanism does not do everything as expected, and now GTK3 does not, either. Thus, relying on the fallback behavior is not a good choice. An example is QT4, it does not have QT4_IM_MODULE when first released, but the variable get added eventually. I've no idea about whether the new variable will work if we don't recompile the world (this question should be answered by a GTK expert), but it shouldn't lead to embarrassing results because it won't cause API/ABI breakage. All in all it's just adding something to existing ones. >> 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. > -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
