On Thu, Dec 29, 2011 at 06:28:49PM +0900, Osamu Aoki wrote: > Hi, > > Wait a moment... please. > > My mail had 2 points. > * bug needs to be responded and dealt properly. (This is the primary point) > * bug seems easy if it is only to add dependency. (This was a small point)
Once this bug was submitted, I had a look at it, for it is a little bug, I want fixed soon, but I forgot to upload the new package, and give no response to the bug. It is my mistake. > This second point should have had some qualifier stating "If this is > really a bug and bug reporter is right, ..." I did not check this in > detail when I posted message. I did not mean to ask you to follow BTS > report without questioning its validity. I did not even know if BTS > report is right. > > On Thu, Dec 29, 2011 at 01:12:33AM +0800, Liang Guo wrote: > > Hi, > > > > I've upload a new one to mentors.d.n and asked Tomas Gorirand to sponsor > > it. > > This upload will fix this problem. > > > > /usr/lib/ibus-sunpinyin is the default install destinationm, IMO, > > ibus-setup-sunpinyin should be called via input window, rather than via the > > command line. > > You mean that this is called via ibus panel and, in that case, this > always works without problem as is? If this is true. Then you can and > should respond so and closed this bug or mark this bug as > wishlist/wontfix with this comment. > > I did not know the answer. Let me see .... hmmmm ... > > My guts feeling is python-gtk2 dependency is enough since we are not > using glade to create UI interface from this dialogue. > > ibus-anthy, ibus-sunpinyin, ibus-pinyin, ... : all depends on ibus > ibus depends on ibus-python > ibus-python depends on python-gtk2 > > So we are OK with dependency. Before I reply this message, I have reproduced this bug, if I remove glade-python2, ibus-setup-sunpinyin will fail to run, so I think ibus-setup-sunpinyin should depends on glade-python2. > > > other ibus input engine, such as ibus-pinyin, put ibus-engine-* > > and ibus-setup-* in /usr/lib directory too. > > Yah... many many program executables are shipped in this way if they are > meant to be > called from within its packaged programs. These are private > executables and they reside in /usr/lib/foo directories. > > /usr/lib/git-core/ is a good example :-) > Thanks for you kindly mention. -- Liang Guo http://bluestone.cublog.cn
signature.asc
Description: Digital signature