customize rime-data path

[GoogleCodeExporter]

i notice that current rime-data path is fixed, point to /usr/share/rime-data/
since there is provide by brise, would it be /usr/share/brise/? or 
/usr/share/rime/data, to still make it compatible with old release,
I'd proposal a build option like something "--data-path=/usr/share/brise" so 
user can pass the value to overide it. for run time package with need the 
equery the path, probably we can use pkg-config --data?
like an quick idea,

Original issue reported on code.google.com by dennis.y...@gmail.com on 13 Aug 2012 at 11:15

[GoogleCodeExporter]

The problem here is that I notice fcitx use /usr/share/rime/brise as the 
searching path which is not compatible with official ..

Original comment by dennis.y...@gmail.com on 13 Aug 2012 at 11:16

[GoogleCodeExporter]

Thanks for the information.

Original comment by chen....@gmail.com on 13 Aug 2012 at 11:57

[GoogleCodeExporter]

I think using /usr/share/rime-data is OK.
It's better than 'brise' in that it better informs the user what it is for, 
especially for those who's not familiar with everything about Rime but the name 
'Rime' alone.

'/usr/share/rime/data' looks cool, but not reasonable enough for a change, 
after having '/usr/share/rime-data' in a recently released package (librime 
0.9.2) that might have already been used by existing users and downstream 
packages.

Hope you understand my concerns. If we'are agreed, I'll summit a patch for 
fcitx-rime to load the shared copy of rime-data by this weekend.

Original comment by chen....@gmail.com on 15 Aug 2012 at 2:42

• Changed title: customize rime-data path
• Added labels: Type-Other, OpSys-Linux, Project-Brise
• Removed labels: Type-Defect

[GoogleCodeExporter]

Hi chen:
  Hey, what I'm arguing here is not what's right or wrong, it's more or less just a kind of your taste, but for our gentoo user/dev, we'd like stick to the convention, it's more appeal to put it under /usr/share/${PN}/ [1], you name the package here as brise, so probably "/usr/share/brise" would be more reasonable. If this happens, yeah, that's change the rules, might be disturb down-stream user, which may not what you or they want. But as long as we do it carefully, we won't break anything.
  So my previous proposal was not really hope you have this kind a change, but a least provide a choice, choice can be more friendly for down-stream distributor.
  If you can considering provide a --data-option= compile time configuration, would be just great, that's helps.
  I find it's may very hard to convince you to change your mind, but instead let me give you a example, see fcitx, it provide a tool which can poke variables configuration path, which is very robust. other package like :fcitx-rime, fcitx-cloudpinyin, can query the addonconfigdir path, and just install what they want there, this scheme is quite clean and neat, also robust(you don't have to hardcoded).

 ~ # /usr/bin/fcitx4-config --help
Usage: fcitx4-config [OPTION]

Known values for OPTION are:

  --package             Fcitx Package Name
  --prefix              Fcitx Install Prefix
  --exec-prefix         Fcitx Binary Prefix
  --libdir              Fcitx Library Prefix
  --includedir          Fcitx Include Prefix
  --addondir            Fcitx Addon Library Dir
  --configdescdir       Fcitx Configure Description File Dir
  --addonconfigdir      Fcitx Addon Config File Dir
  --imconfigdir         Fcitx Input Method Config File Dir
  --help                display this help and exit
  --version             output version information

 ~ # /usr/bin/fcitx4-config --addonconfigdir
/usr/share/fcitx/addon

 ~ # qfile  /usr/share/fcitx/addon
app-i18n/fcitx (/usr/share/fcitx/addon)
app-i18n/fcitx-rime (/usr/share/fcitx/addon)
app-i18n/fcitx-ui-light (/usr/share/fcitx/addon)
app-i18n/fcitx-cloudpinyin (/usr/share/fcitx/addon)

[1] http://devmanual.gentoo.org/general-concepts/filesystem/index.html

Original comment by dennis.y...@gmail.com on 15 Aug 2012 at 3:18

[GoogleCodeExporter]

OK, I'll add an option.

By the way...
I'm not familiar with Gentoo, just being curious about its packaging system 
because it sounds that you have to name it '/usr/share/brise' because PN=brise 
and that PN is taken from the name of source repository.
Is it required a Gentoo package name should be related to name of the source 
repository? Otherwise I'd suggest 'rime-data' as the package name, if possible. 

Original comment by chen....@gmail.com on 15 Aug 2012 at 3:50

• Changed state: Accepted

[GoogleCodeExporter]

It would be fair if you going to rename "brise" to "rime-data", ^-^ . Actually 
Gentoo *is* the distribution which care the build system more than others, 
there *are* cases which upstream name the package "foo" but provide source 
tarball "bar", and Gentoo do have ways to get over this. But this is just not 
decent. I hope I don't put you into a hard situation. Since this is not very 
big problem. Also, I personally can have the patches carry on locally, but just 
not elegance.
My previous intention of writing this is just want to make it better, more 
friendly,  don't mind!

Original comment by dennis.y...@gmail.com on 16 Aug 2012 at 1:21

[GoogleCodeExporter]

Sorry for having delayed this for weeks.

Now librime and brise are split into separate packages.

to use a custom data directory (for example '/usr/share/brise'):

    cd brise; make; sudo make RIME_DATA_DIR=/usr/share/brise install

then:

    mkdir -p ibus-rime/build; cd ibus-rime/build
    cmake -DRIME_DATA_DIR=/usr/share/brise ..
    make

the same option works for lotem/fcitx-rime.

Original comment by chen....@gmail.com on 1 Sep 2012 at 9:31

• Changed state: Fixed