[Pkg-ime-devel] [ibus] about ibus input engine packaging.
ueno at unixuser.org
Mon Jun 10 04:05:53 UTC 2013
Ma Xiaojun <damage3025 at gmail.com> writes:
> On Mon, Jun 10, 2013 at 7:07 AM, Daiki Ueno <ueno at unixuser.org> wrote:
>> Well, I don't oppose to use <setup> at all, as for the first two you
>> mentioned, but I'm opposing to use it for the unnecessary situation
>> (e.g. band-aid for Debian's libexec problem).
>> From this point of view, you have only succeeded to convince the
>> sunpinyin and ibus-cangjie upstreams. What about ibus-chewing,
>> ibus-hangul, ibus-skk, ibus-unikey, etc? For ibus-skk, I don't like to
>> merge such a change, which will be unnecessary in the future, once...
> Do you need some aid on English reading or primary school math? How
> can you read "3+1" as "2"?
As I wrote above, I excluded 2 from 3, because those two are not
for the libexec problem. So, 1 + 1 = 2.
> Show me how ibus-setup in git repo launch a
> ibus-setup-<engine>.desktop . Show me the code please; I don't see any
> new commits after this discussion.
I don't see any reason to implement it so hasty, like your scattered
email replies. Also please don't misunderstand. I just brought up a
possibility and argued that it would be better than your <setup> idea,
and didn't argue the desktop idea the only option.
> I argued for storing all ibus-setup-* in one directory previously.
Oh, you were not pushing the idea to set <setup> in every engine
package? Then I must apologize. Installing ibus-setup-* (or a symlink
to it) under ibus package's libexecdir (i.e. /usr/lib/<arch>/ibus)
sounds a reasonable solution and should be multiarch safe, although
ibus-1.0.pc currently doesn't expose libexecdir variable.
More information about the Pkg-ime-devel