Rainer Orth wrote: > Fuyuki, > >>>> 4.5. Interfaces: >>>> >>>> INTERFACE NAME STABILITY NOTE >>>> >>>> ----------------------------------------------------------------------- >>>> /usr/bin/ibus-daemon Uncommitted message bus daemon >>> How is this started? Via SMF at boot? If so, we need FMRI etc. Can it >>> ever be invoked manually be a regular user? If not, it belongs into >>> /usr/sbin (if manually invoked by sysadmins) of /usr/lib. >> It's user process started via gnome-session(1). > > but if there is no reason to start this manually, it's probably better > located in /usr/lib/ibus.
As I replied to Joerg, we'd like to keep /usr/bin/ibus-daemon. (FYI, iiim daemons also have been located in /usr/bin) > >>>> /usr/bin/ibus-setup Uncommitted setup launcher >>> Same here: who invokes this? >> It's invoked via System->Preference->iBus Setup or by manual. > > Ok, if manual invokation is an option, the location is fine. > >>>> /usr/libexec/ibus-x11 Uncommitted ibus XIM fontend/agend >>>> >>>> /usr/libexec/ibus-gconf Uncommitted config backend by >>>> gconf-python >>>> /usr/libexec/ibus-ui-gtk Uncommitted panel GUI by pygtk >>> There is no /usr/libexec in Solaris: either belongs into /usr/lib (or >>> /usr/lib/ibus) or /usr/share/ibus if architecture independent. >> In order to reduce Solaris patches, we followed the original directories. >> If /usr/libexec/ is not allowed, we will change them to /usr/lib/ibus/ibus-*. > > Fine, thanks. I've updated the material. > >>>> /usr/lib/libibus.so Uncommitted ibus C binding SDK library >>> That's only the compilation symlink. What's the real filename and SONAME? >> /usr/lib/libibus.so.0.0.0 >> will update the material. > > The SONAME will more likely be libibus.so.0 in this case. Please check > with dump -Lv. The SONAME was libibus.so.0. I've updated the material. > >>>> /usr/libexec/ Uncommitted IME launcher >>>> ibus-engine-<IME_NAME> >>>> /usr/libexec/ Uncommitted IME setup launcher >>>> ibus-setup-<IME_NAME> >>> Same as above: no /usr/libexec. >> If /usr/libexec/ is not allowed, we will change them to >> >> /usr/lib/ibus/ibus-engine-<IME_NAME> (I know this is better) >> /usr/lib/ibus/ibus-setup-<IME_NAME> (I know this is better) >> or >> /usr/lib/ibus-engine-<IME_NAME> >> /usr/lib/ibus-setup-<IME_NAME> > > Please use the first variant to avoid needlessly cluttering /usr/lib. OK. I've updated the material. > >>>> /usr/share/ibus-<IME_NAME> Uncommitted IME modules >>>> *IME_NAME is among [anthy, chewing, hangul, m17n, pinyin, table] >>> Why the mess: better move this to /usr/share/ibus/<IME_NAME> to avoid >>> cluttering /usr/share even more. >>> >>>> /usr/share/ibus-table/* Uncommitted ibus-table engine and >>>> code-tables >>> Same here: better /usr/share/ibus/table or some such. >> In fact I've been feeling the same way, but again, we followed the >> original directories to reduce Solaris patches. > > Understood, but perhaps the changes can even be fed upstream? At least in > Solaris, there seems to be a strong preference to have exactly one > directory in /usr/share for each application, otherwise the directory > quickly becomes almost impossible to browse. > >> I understand these changes are not mandatory, but better to have. > > Some of them might be optional, but at the change away from /usr/libexec is > mandatory. > >> I'll discuss with the project team and come back. > > Excellent, thanks. /usr/share/ibus/ has been used for ibus core files. We examined /usr/share/ibus-IME/, but unlike /usr/libexe change it's not easy. It seems we need to create several patches for each IME and ibus core. The project team would like to keep the current directories at least for this time. Thanks, Fuyuki > > Rainer > > ----------------------------------------------------------------------------- > Rainer Orth, Center for Biotechnology, Bielefeld University
