輸入法打包套件經驗談

底下內容隨便寫寫，沒特別整理。

大致以 deb 為主，不過其它類型的套件很多原理/注意事項也一樣，所以有志從事打包套件的人不妨看仔細點。

1. configure 的那些事

1. 這幾年來 pkg-config 幾乎一統江湖，但以前許多 lib 都不支援，所以各大 build system 都要各顯神通想辦法偵測，有時候偵測不到還要 user 自己加參數指定 lib path 之類的。

1. 以 gcin 來說，libXtst 和 Qt3 以前長期不支援 pkg-config, 所以偵測不易。gcin configure 一直用很克難的方式偵測 Qt3, 而 Xtst 則是乾脆就不偵測 XD

1. 現在主流的發行版好像 Xtst 都有收 pkg-config 了，所以 gcin 可以考慮來偵測一下了。

2. rpath 的那些事

2. 當初送 gcin 進 debian 官方時，我以為 debian 不收使用 rpath 的軟體，所以很辛苦的 patch gcin makefile 把 rpath 拿掉。

2. 不過當時 gcin 的 rpath 有讀取 . 這個目錄，算是安全漏洞，所以我誤打誤撞的 patch 反而消除了 gcin deb 的安全隱患 XD

2. 現在的 gcin 已經把那個漏洞補上了，所以包 deb 時沒必要把 rpath 拿掉，現在那些 makefile patch 基本上沒啥意義。

3. Qt3 immodule 的那些事

3. Qt3 immodule 因為會影響 binary compatibility，一直沒有收錄到 upstream, 而是以 patch 的形式存在。

3. 有些 distro 有收這 patch, 有些 distro 沒收, 而像 gentoo 這種 source based distro 則是可自選要不要收。

3. 總之實在很麻煩。另外一但包了 Qt3 immodule, gcin 套件包就會依賴 Qt3。一個 GTK+ 軟體依賴 Qt3 實在是讓人很不爽，所以往往只能選擇把 Qt3 immodule 拆開，變成兩個套件…

3. 於是問題就更麻煩了。因為 QT_IM_MODULE=gcin 時，如果系統沒有 Qt3 immodule 往往無法在 Qt3 軟體上使用 gcin, 必須改成 QT_IM_MODULE=xim 才行。而 user 又不一定有安裝 Qt3 immodule...導致 QT_IM_MODULE 這個變數必須動態偵測…

4. immodule 相依性的那些事

4. 因為 immodule 依賴各種 lib 很麻煩，所以 gcin 曾經嘗試過把不必要編入的 lib 拿掉。

4. 在絕大部份 *比較正常* 的軟體裡，gtk2/gtk3 immodule 可以不依賴 libgtk, qt3/qt4 immodule 可以不依賴 libqt, 這樣的好處就是可以把所有 immodule 都包到同一個套件裡，避開 QT_IM_MODULE / GTK_IM_MODULE 動態偵測的麻煩。

4. 不過很不幸的，openoffice / libreoffice / python 等等無法正常使用這種「不編入 libgtk/libqt」的 immodule, 所以 gcin 只好又改回來了。目前 gcin 所有的 immodule 都要分別依賴 gtk2/gtk3/qt3/qt4, 打包套件也往往必須拆開來包。如果不拆，就會變成安裝 gcin 要順便安裝 gtk2 + gtk3 + qt3 + qt4...

5. im-switch 的那些事

5. 幾年前各大 distro 都沒有專門的輸入法設定程式，大家都各搞各的，user 都到處亂抄。有人寫在系統 /etc, 有人寫在 bash conf（換了 shell 就沒輸入法用），有人發明了各種各樣的錯誤設定，其中許多錯誤到現在都還廣為流傳。

5. （題外話）有個很有名的錯誤設定到現在都還有不少人用，XIM 環境變數。例如 XIM=gcin 這樣的設定，實際上是完全沒作用的。就我所知，現在還有惡搞這個設定的 distro 已經很少了，但還是看到很多人這樣用…

5. im-switch 本來是從 fedora 開始的，debian 抄了過來，亂搞成自己的奇怪架構，然後 ubuntu 也抄了過去，又亂搞成 ubuntu 的奇怪架構。fedora 很快就拋棄了 im-switch 另起爐灶，debian / ubuntu 則是縫縫補補漸漸統一。不過現在 debian / ubuntu 又搞了腦殘的 im-config, 可能會漸漸把 im-switch 全換成 im-config

5. gcin 的 im-switch 大致上不難，也沒啥問題，比較囉唆的就是上面說的 QT_IM_MODULE 偵測問題，要依據 user 是否安裝 Qt immodule 決定參數內容

6. gtk immodule 的那些事

6. gtk immodule 從出現以來就完勝 XIM, 所有特性都比 XIM 好。不過 scim 因為 g++ ABI 相容性問題，導致 scim gtk immodule 穩定性十分淒慘，讓許多人誤以為 gtk immodule 設計不良。實際上既不是 gtk immodule 的錯，也不是 scim 的錯，而是 g++ 的錯（不是 c++ 的錯）。

6. gcin 基本上建議一律使用 GTK_IM_MODULE=gcin, 不過在歷史上也曾被 scim 黨人質疑過，認為應該改成 GTK_IM_MODULE=xim

7. gtk-query-immodules-?.0 的那些事

7. gtk immodule 需要用 gtk-query-immodules-[23].0 更新 list。debian / ubuntu 最早是要各大輸入法套件自己在安裝/移除後呼叫，更新 list。後來改成在 gtk 打補丁，使用 immodule-files.d 目錄。

7. 為了支援這個惡搞的補丁，debian / ubuntu 又開發了 dh_gtkmodules 這個 debhelper 來生成 list。

7. 目前最新的做法是把這惡搞補丁拿掉，改用 dpkg 的 triggers 自動呼叫 gtk-query-immodules-?.0

7. 看起來一切都很美好，不過還有不少老舊 release 還在用 immodule-files.d, 所以為了方便起見還是要提供一下…

8. dh 的那些事

8. 打包 deb 實際上是很自由的，不過一般來說建議使用 debhelper。

8. 在我當 gcin deb maintainer 時，dh 這指令還沒推出，debian/rules 都得寫得又臭又長，還得處理 patch 的問題。打包還需要安裝 dpatch / quilt 之類的玩意兒。

8. 現在 dh 這指令可以讓 debian/rules 變得很簡單，不過需要較新版的 debhelper 才能使用。

9. 拆？還是不拆？

9. 前面說過，immodule 的依賴讓 distro 官方包勢必得把 immodules 拆成另一個 deb, 不然就會發生安裝 gcin 要同時安裝 gtk2/gtk3/qt3/qt4 的慘事。

9. 官方包是應該這樣沒錯啦，但非官方包就不用管那麼多了。所以 gcin 1.6.4~pre10 以上版本提供的 gcin-deb 指令，是把所有 immodule 都跟主程式包在一起，然後動手腳讓那些依賴不顯示。只是不顯示而已，實際上還是要依賴 gtk2/gtk3/qt3/qt4。

10. gen-deb 的品質？

10. gen-deb 的設計是盡量簡單、不惡搞、不打補丁、品質維持在還算不錯的程度，但遠遠沒有達到正式官方 deb 該有的品質。

10. 因為 debian / ubuntu 目前的官方 gcin deb 品質甚糟，非官方 repository 也往往沒跟上最新版的 gcin, 所以弄個 gen-deb 給大家測試用。