每特17劃

及時當勉勵 2004/06/07

OpenVanilla套件打包二三事 — 2007-03-13

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