RPM的基礎(chǔ)知識

RPM是RedHat Package Manager的縮寫,意即RedHat(紅帽子)軟件包管理器。(RedHat是美國有名的LINUX公司,網(wǎng)址:http://www.redhat.com
對于一個操作系統(tǒng)來說,不能沒有一個象樣的軟件包管理器。沒有軟件包管理器的幫助,操作系統(tǒng)發(fā)行版的制作者將面臨這樣或那樣的難題,用戶安裝,升級,卸載與發(fā)布軟件包也將是非常麻煩的,系統(tǒng)管理也容易出現(xiàn)問題。相反,有了專門的軟件包管理器,軟件制作者易于制作和發(fā)行自己的軟件了,而對于普通用戶來說,軟件包的安裝維護(hù)將變得非常方便了。這種
情況,對于一個操作系統(tǒng)的推廣也會起到良好的促進(jìn)作用。RPM就是隨著RedHat LINUX發(fā)行版的流行而迅速推廣開來的,二者的表現(xiàn)相得易彰。

　　RPM先行者
　　最初的時候,LINUX系統(tǒng)的發(fā)布并沒有使用什么軟件包管理器。隨著時間的推移,RedHatmLINUX開發(fā)者意識到開發(fā)一個軟件包管理器的重要性,于是開發(fā)出RPP這個管理器。

RPP相對于RPM雖然是簡單的,但已有了幾項(xiàng)重要的功能,如打一個簡單的命令就可以實(shí)現(xiàn)軟件的安裝與卸載,包中可含有安裝前后與卸載前后執(zhí)行的腳本程序,還可以隨時校驗(yàn)已安裝的軟件包,查詢功能也很強(qiáng)大。

RPP的缺點(diǎn)在于,RPP打包是基于特別修改過的(針對RPP)源代碼的,因而這些源代碼并非是純正的源代碼。由于這個原因,當(dāng)軟件包開發(fā)者想建立大量不同的軟件包時,將面臨眾多技術(shù)面的問題。RPP也不能保證當(dāng)前的執(zhí)行程序是基于打包過的源程序的,并且RPP不支持多處理器體系結(jié)構(gòu)。與RPP同時開發(fā)的,還有PMS(即package
management system,軟件包管理系統(tǒng)),這是另一群LINUX愛好者開發(fā)的。PMS采用的是純正的源代碼,它允許軟件包制作者很快釋出一個軟件的最新版本,并且可以立刻看到該軟件的變化。RPM采用了這一明智的做法,這也是PMS對RPM的一項(xiàng)重大貢獻(xiàn)。PMS的缺點(diǎn)是查詢功能不強(qiáng),沒有包校驗(yàn)功能,不支持多體系結(jié)構(gòu),數(shù)據(jù)庫設(shè)計也不好。在RPP和PMS之后,Rik
Faith和Doug Hoffman開發(fā)了PM管理器。該管理器整合了RPP與PMS的許多功能,但是數(shù)據(jù)庫設(shè)計還不強(qiáng),依然不支持多體系結(jié)構(gòu)。

　　RPM開發(fā)
　　此后,Marc Ewing和Erik Troan兩人在吸取RPP,PMS,PM設(shè)計經(jīng)驗(yàn)的基礎(chǔ)上,用PERL語開發(fā)了RPM軟件包管理器,即RPM1.0版。

　　其成功之處在于:
　　可自動處理配置文件;
　　可重建大量的軟件包;
　　易于使用。
　　其不足之處在于:
　　 程序大,運(yùn)行速度慢,因?yàn)樗怯肞ERL這種解釋型的語言寫的;
　　數(shù)據(jù)庫功能太弱;
　　不支持多體系結(jié)構(gòu);
　　包裹文件格式不可擴(kuò)展。

　　針對RPM1.0的弱點(diǎn),RPM的開發(fā)者再度努力,將RPM升級到2.0,3.0和現(xiàn)在的4.0版本。他們主要做了以下幾點(diǎn):
　　用C重寫了程序,這極大地提高了RPM的運(yùn)行速度。
　　RPM數(shù)據(jù)庫格式進(jìn)行了再設(shè)計,重點(diǎn)從性能和可靠性兩方面提高。
　　軟件包格式也進(jìn)行了再設(shè)計,方便以后的擴(kuò)展和升級。
　　建立了rpmlib(RPM函數(shù)庫),方便其它程序調(diào)用RPM。
　　增加多體系支持,方便RPM跨平臺使用(不論是x86體系,還是sparc等其它體系)。
　　網(wǎng)上的RPM
　　RPM官方網(wǎng)址為http://www.rpm.org,

　　小結(jié)
　　如今的RPM使得軟件包安裝與卸載更容易,校驗(yàn)已安裝的軟件包是否正常也容易,將程序(源程序或執(zhí)行程序)打包也簡單了,跨平臺的支持,遵循GPL版權(quán)發(fā)布源代碼,使得RPM得到更廣泛的應(yīng)用與推廣。RPM正在風(fēng)靡LINUX與非LINUX世界。如果你想了解甚至精通RPM,那么請跟我來吧!