OpenVanilla套件打包二三事
在寫 UCIMF 的趨使下，對 OpenVanilla 的安裝方法並不陌生。
雖然手動安裝不難，但總是希望能直接用套件的方式來安裝程式和模組。
繼前陣子包了給 Debian 的實驗包之後，一直也很想試 Gentoo 的打包。
經過幾天的嘗試，幸運的得到初步的成果。
一開始的時候，煩惱要怎麼指定程式碼的位置，一般都是給一個 tar.gz 的 URL 然後下載解壓縮。
不過 OpenVanilla 主要是用 SVN 作為存放的方式，所以行不通，於是就暫時寄望在 Tarball 出現上。
這時候剛好遇到 psilotum 秀了 FreeBSD上 的 OpenVanilla 的 Ports 給我看，才發現 Ports 已經有人包好這些套件，我便想， Portage 上也有類似的工具才對。
有了靈感後，很快就找到 Portage 對於 SVN 這類的處理方式了。
主要的作法是，先 inherit subversion 這個 eclass, 然後再用 ESVN_REPO_URI 的參數來指定位置。
遇到比較分散的檔案，則可以改寫 src_unpack() 以符合需求。不熟悉的地方則可以先參考已經寫好的 ebuild ，像是 uim-svn 。
回顧這兩次作 Debian 和 Gentoo 的 Package 的經驗，發現製作原理有很多共同的地方。 作 Debian 的包裝時，發現整個 OpenVanilla Modules 的目錄只要設好一個套件產生的規則，就能把整個目錄下所有的模組都打包成個別的套件。 因此原本以為要作 10 幾個重複的工作，居然一次就作完了。 這讓我印象非常非常的好。能在套件的維護者只需要維護一個 Source Package 的情況下，產生許多 Sub Binary Package 供使用者選擇，是極大的優點。 而 Gentoo 特別的地方(也是 FreeBSD Ports 的特色)，則是直接抓源本的原始碼來編譯的風格。 這個風格的好處是在我開始作 UCIMF 之後才慢慢有感覺的。 因為我體會到，對許多還在發展中的專案，維護一份 Tarball 是一件很困擾的事。 最主要的原因是，許多地方都還在增減修補，很難取捨出一個點作為一個穩定的釋出，而要等套件的製作，更是一個漫長的過程。 這時候能夠透過 CVS 、 SVN 這一類的方式取得原始碼來編譯，對許多發展中的專案來說，真的是一個很棒的特色。
從一開始的 User ，到寫專案後學了一些 Developer 東西，在今天作了這些東西之後，感覺又多了一個 Packager 的角色。 對我來說，在這三者的使用情境中轉換，並不是那麼方便。是不是有個套件機制可以將這三者融合在一起呢? 像是我今天想改一個程式的功能，我能很方便的取得源本的原始碼，在本機修改後，能直接套用在套件裡作編譯和安裝，完成後並能輕易的釋出和分享。 今天看來，相關的環境條件都蠻成熟了，說不定已經有這樣子的整合式套件系統架構存在也說不定。
或許在可見的將來，這些開發平台的整合，也能像 Wiki 對文件發展所帶來 2.0 的影響一樣，提供開發者一個互動性更高、更流暢的開發環境。
Package 2.0 ? 嗯…