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 ? 嗯...