精通RPM之認識篇(轉)

精通RPM之認識篇(轉)[@more@]

RPM是RedHat Package Manager的縮寫,意即RedHat(紅帽子)軟體包管理器。(RedHat是美國有名的LINUX公司,網址:)

對於一個作業系統來說,不能沒有一個象樣的軟體包管理器。沒有軟體包管理器的幫助,作業系統發行版的製作者將面臨這樣或那樣的難題,使用者安裝,升級,解除安裝與釋出軟體包也將是非常麻煩的,系統管理也容易出現問題。相反,有了專門的軟體包管理器,軟體製作者易於製作和發行自己的軟體了,而對於普通使用者來說,軟體包的安裝維護將變得非常方便了。這種 情況,對於一個作業系統的推廣也會起到良好的促進作用。RPM就是隨著RedHat LINUX發行版的流行而迅速推廣開來的,二者的表現相得易彰。

RPM先行者

最初的時候,LINUX系統的釋出並沒有使用什麼軟體包管理器。隨著時間的推移,RedHatmLINUX開發者意識到開發一個軟體包管理器的重要性,於是開發出RPP這個管理器。

RPP相對於RPM雖然是簡單的,但已有了幾項重要的功能,如打一個簡單的命令就可以實現軟體的安裝與解除安裝,包中可含有安裝前後與解除安裝前後執行的指令碼程式,還可以隨時校驗已安裝的軟體包,查詢功能也很強大。

RPP的缺點在於,RPP打包是基於特別修改過的(針對RPP)原始碼的,因而這些原始碼並非是純正的原始碼。由於這個原因,當軟體包開發者想建立大量不同的軟體包時,將面臨眾多技術面的問題。RPP也不能保證當前的執行程式是基於打包過的源程式的,並且RPP不支援多處理器體系結構。

與RPP同時開發的,還有PMS(即package management system,軟體包管理系統),這是另一群LINUX愛好者開發的。PMS採用的是純正的原始碼,它允許軟體包製作者很快釋出一個軟體的最新版本,並且可以立刻看到該軟體的變化。RPM採用了這一明智的做法,這也是PMS對RPM的一項重大貢獻。PMS的缺點是查詢功能不強,沒有包校驗功能,不支援多體系結構,資料庫設計也不好。

在RPP和PMS之後,Rik Faith和Doug Hoffman開發了PM管理器。該管理器整合了RPP與PMS的許多功能,但是資料庫設計還不強,依然不支援多體系結構。

RPM開發

此後,Marc Ewing和Erik Troan兩人在吸取RPP,PMS,PM設計經驗的基礎上,用PERL語開發了RPM軟體包管理器,即RPM1.0版。

其成功之處在於:

可自動處理配置檔案;

可重建大量的軟體包;

易於使用。

其不足之處在於:

程式大,執行速度慢,因為它是用PERL這種解釋型的語言寫的;

資料庫功能太弱;

不支援多體系結構;

包裹檔案格式不可擴充套件。

針對RPM1.0的弱點,RPM的開發者再度努力,將RPM升級到2.0,3.0和現在的4.0版本。他們主要做了以下幾點:

用C重寫了程式,這極大地提高了RPM的執行速度。

RPM資料庫格式進行了再設計,重點從效能和可靠性兩方面提高。

軟體包格式也進行了再設計,方便以後的擴充套件和升級。

建立了rpmlib(RPM函式庫),方便其它程式呼叫RPM。

增加多體系支援,方便RPM跨平臺使用(不論是x86體系,還是sparc等其它體系)。

網上的RPM

RPM官方網址為該網站刊登有RPM的最新訊息,有關於RPM的說明文件,還可下載最新的RPM軟體原始碼和執行程式碼,不妨常去看看。

小結

如今的RPM使得軟體包安裝與解除安裝更容易,校驗已安裝的軟體包是否正常也容易,將程式(源程式或執行程式)打包也簡單了,跨平臺的支援,遵循GPL版權釋出原始碼,使得RPM得到更廣泛的應用與推廣。RPM正在風靡LINUX與非LINUX世界。如果你想了解甚至精通RPM,那麼請跟我來吧