轉(zhuǎn)自：http://bbs.chinaunix.net/viewthread.php?tid=609471

要了解 tarball 與 rpm 的差別, 不妨先從軟件的產(chǎn)生開始談吧.

簡單來說, 現(xiàn)今的電腦, 之所以能運(yùn)作, 是因?yàn)樗鼤?huì)處理 0 跟 1 , 但問題卻也是只能處理 0 跟 1 .
因此, 要讓電腦能執(zhí)行的軟體程式, 必需以 0 跟 1 的二進(jìn)位(binary)格式出現(xiàn), 我們稱之為---執(zhí)行碼(executable).
而且, 不同的 CPU 所執(zhí)行的格式都不盡相同, 我們稱之為硬件平臺(tái)(platform).
以個(gè)人電腦來說, 最常見的硬件平臺(tái)多是 Intel 公司設(shè)計(jì)(或兼容)的 CPU, 常稱為 i386 或 x86 .

然而, 二進(jìn)位格式卻造成程式設(shè)計(jì)師撰寫程式的難度太高了! (呵, 別懷疑, 早期的確如此~~)
聰明的人們, 于是選用了別種較為易懂的方式來轉(zhuǎn)寫, 也就是我們常說的"程式語言"了.
我們稱這些寫用程式語言撰寫的代碼為---源代碼(source code).程式語言很多, 在 Unix/Linux 世界裡, C 語言是最傳統(tǒng)也最常用的程式語言.


在這基礎(chǔ)上, 我們需知道如下事實(shí):
1) 我們可用的程式語言很多種.
2) 可供執(zhí)行的硬件平臺(tái)也很多種.
3) 用程式語言寫好的源代碼并不會(huì)自動(dòng)變成二進(jìn)位格式.
這就是"編譯器(compiler)"上場的時(shí)候了. 換句話來說:
--- 寫好的源代碼必須針對(duì)不同的硬件平臺(tái)進(jìn)行編譯才能能產(chǎn)生執(zhí)行碼.
不同語言的源代碼及不同硬件平臺(tái)均需要不同的編譯器來執(zhí)行這項(xiàng)工作.
要是你用 C 來寫源代碼的話, 那最常見的編譯器就是 C Compiler, 簡稱為 cc .
然而 cc 也有很多不同的版本, 功能效能及作業(yè)平臺(tái)或有所不同.
Linux 最常見的就是 GNU 的 C Compiler, 簡稱為 gcc .

當(dāng)你寫好 c code, 同時(shí)裝好了 gcc, 那你就可執(zhí)行 gcc 編譯出執(zhí)行碼.
然后, 再將編好的執(zhí)行碼複制到相關(guān)路逕, 人們便可在這臺(tái)機(jī)器上執(zhí)行該程式了.
我這裡暫不介紹如何寫 C 代碼, 也不介紹怎麼跑 gcc, 有待大家自己學(xué)習(xí).
事實(shí)上, 越複雜的程式, 代碼越長, 也越難設(shè)計(jì)與為護(hù), 而 gcc 可選用的參數(shù)也越多.
我這裡也暫時(shí)不介紹函式庫(library)的概念了, 但其實(shí)這方面還可大書特書的.
我非常建議讀者搞懂函式庫的概念, 尤其是靜態(tài)(static)與動(dòng)態(tài)(dynamic)函式調(diào)用方式的差別.
因?yàn)檫@會(huì)扯上執(zhí)行環(huán)境的依賴性及程式的移植性, 也就是所謂的---軟件依存關(guān)系(dependence).
嗯, 還是先請(qǐng)大家自己琢磨吧, 要是日后有機(jī)會(huì)的話, 再回來跟大家介紹好了.

到此為止, 相信大家已經(jīng)知道軟件是怎麼蹦出來的了!
然而, 如下問題, 請(qǐng)大家不妨老實(shí)作答:
1) 你會(huì)寫源代碼嗎?
2) 你會(huì)得執(zhí)行 gcc 及相關(guān)參數(shù)嗎?
(呵... 坦白講, 我就不很懂了!)
而且, 就算你懂了, 那:
3) 你愿意每次安裝軟件都敲上百行的 gcc 命令嗎?
(呵... 同樣的, 我也不愿意!)
將心比心, 那些普通電腦使用者呢? 他們又作何感想呢?
難道擁抱軟件非要如此折騰不可?

這裡, 請(qǐng)你先記著這句話:
--- 軟件之所以進(jìn)步, 就是因?yàn)槿藗儠?huì)隨時(shí)隨地將存在的問題解決掉!
前面提及的, 從二進(jìn)位撰寫改為從源代碼撰寫, 就是一個(gè)很了不起的進(jìn)步. 更別提古老的"打孔卡"年代了!
然而, 這進(jìn)步是不夠的... 人們并不滿足啊~~~
于是, 就有了 make 這個(gè)程式出現(xiàn)了.
簡單而言, make 就是讀入一份預(yù)先編寫好的 Makefile, 然后自動(dòng)的幫我們完成所有的編譯工作.
具體的 Makefile 格式, 我這裡也暫時(shí)略過, 還是留給大家自行學(xué)習(xí). (我這裡只想講概念)
能理解 Makefile 帶來的進(jìn)步很重要, 因?yàn)楹竺嫣岬降?rpm spec 也是源于相同的理念.
從此, 我們只需跑幾個(gè)簡單的 make 指令, 就能代替過往上百成千行的 gcc 命令了!

what a wonderful thing!
okay, 不得不承認(rèn) Makefile 曾經(jīng)為人們帶來過一段時(shí)間的滿意.

it's good, but not good enough!
還有啥不滿足呢?
隨著電腦的普及, 軟件的散播速度也大大的提高了.
且, 面臨的各種不同的執(zhí)行環(huán)境差異也越來越廣.
人們慢慢發(fā)現(xiàn): 單一的 Makefile 沒法滿足所有環(huán)境的需求!

怎麼辦?
呵.... 回到前面的老話:
--- 軟件之所以進(jìn)步, 就是因?yàn)槿藗儠?huì)隨時(shí)隨地將存在的問題解決掉!
于是, 聰明的人們, 開始撰寫一些環(huán)境偵查工具, 大多是一些 script 語言(shell, perl 等等),
讓使用者可以先執(zhí)行之, 然后按不同的偵查結(jié)果自動(dòng)修改 Makefile.
同時(shí), 用心的作者, 還允許使用者透過各種參數(shù), 來指定特殊的需求.

yeah... perfect?!
Nooooooooooooooot yet!!
又怎了?
唉呀, 親愛的朋友啊, 要是我不講, 你怎知道原來還可以這樣玩呢?
更何況那些快快樂樂只想跑應(yīng)用的普通用戶呢?! 就算我這樣講, 對(duì)他們來說, 還是一頭霧水啊~~~

don't worry!
--- 軟件之所以進(jìn)步, 就是因?yàn)槿藗儠?huì)隨時(shí)隨地將存在的問題解決掉!
于是, 作者一不做二不休, 乾脆將所有步驟及可能的環(huán)境需求與操作, 寫成文檔, 讓使用者慢慢讀就是了.
這, 就是 README, INSTALL 這類文檔存在的意意了!

呵... 到這裡, 你是否豁然開朗了? 原來, 我們之前常看到人們裝軟件都是如此跑的:
1) less README INSTALL
2) ./configure
3) make
4) make install
只要你能理解前面所講的, 那, 你就能了解為何都是這幾個(gè)步驟了... ^_^
這, 就是人們常說的"源代碼安裝"方式了, 或稱為 tarball .
(嗯, tarball 其實(shí)還要扯上 tar 與 gzip/gunzip 等程式, 我這裡也暫時(shí)不談了.)

然而, 問題真的解決了嗎?
你以為真的從此就天下太平了嗎?
若你認(rèn)為滿足的話, 那我再來問你幾個(gè)問題:
1) 你知道系統(tǒng)一共裝了哪些軟件嗎?
2) 它們是誰提供的? 版本為何?
3) 你知道剛剛裝的軟件裝哪去了?
4) 你知道自從安裝后, 有哪些文件被修改過?
5) 這個(gè)軟件要依存哪些其他軟件嗎?
6) 又有哪些軟件依存你這個(gè)軟件呢?
7) 你可以放心的移除它或升級(jí)它嗎?
8) 你知道其他伙伴又裝了哪些改了哪些嗎?
9) 你知道這每一臺(tái)機(jī)器的軟件狀況嗎?
9) 若你要將職務(wù)交接給別人, 你能交代清楚嗎?
10) 要是你從別人接管過來呢?
等等又等等....
這些一直以來都是軟件管理上必答的問題. 然而, 你的答桉又有幾多呢?!
別跟我說, 你可以耍賴不答哦. 要是你自己的系統(tǒng), 隨便你怎搞都行.
但, 要是你是每月都領(lǐng)別人薪水的話, 這些基本問題答不出來, 你還好意思拿? 你還有臉說要加薪?

嗯????
你在冒冷汗了嗎? 朋友?
呵... 不用內(nèi)疚啦, 不只是你, 很多人都碰到同樣的問題啊...
--- 軟件之所以進(jìn)步, 就是因?yàn)槿藗儠?huì)隨時(shí)隨地將存在的問題解決掉!
那, 請(qǐng)問, 接下來, 換作是你的話, 怎麼解決上述那些問題?
1) 用腦記?
2) 用筆寫?
3) 請(qǐng)秘書?
4) 置之不理?
呵... 朋友, 別忘了你是個(gè)聰明的 IT 專業(yè)人員哦~~~
5) 寫成電子文檔?
夠了嗎? 當(dāng)然不夠!
6) 做成數(shù)據(jù)庫(database)?
yeeeeeaaaaahhhhhhhhhhhh! Bingo! 你中獎(jiǎng)了!
你從事 IT 這麼久了, 難道沒想到: 凡是要備桉查詢的東西就交給數(shù)據(jù)庫吧!
是的! 我們也可用數(shù)據(jù)庫來追蹤及管理我們的軟件資訊啊, 不是嗎?
事實(shí)的確就是如此!

不過, 你會(huì)寫數(shù)據(jù)庫嗎? 就算會(huì)寫, 能否用來管我們的軟件?
(老實(shí)又坦白的說: 老子就不會(huì)!)
怎樣? 難道不可用別人的嗎?
呵.... 是的: 用別人的勞動(dòng)成果 --- 這跟你不用自己寫源代碼的道理是一樣的!

那, 用誰的呢?
其實(shí)答桉已經(jīng)呼之欲出了 --- Redhat Package Management(RPM) 就是其中佼佼者.
這個(gè)詞中的 Package 指的就是我們裝在電腦上的軟件了.
(Package Managemnet 跟 Software Management 其實(shí)是有差別的, 我們這裡談的是 package .)
RPM 有啥能耐呢?
說穿了, 就是一個(gè) database 而已.
有了它, 前面問到的關(guān)于軟件管理的問題全部都可以輕鬆就回答出來了.
呵... 關(guān)于 rpm 指令的運(yùn)用, 我這裡同樣略過, 只講原理, okay?

okay!
那麼, rpm db 又怎麼冒出來的呢?
嗯..... 這個(gè)就要扯上 rpm spec 了.
還記的前面提到的 Makefile 嗎?
若你記得 Makefile 可以自動(dòng)跑 gcc 的話,
那麼一個(gè)簡單的 rpm spec 就是幫你自動(dòng)跑 configure 跟 make 那些指令!
然后, 再額外增加了數(shù)據(jù)庫的資料項(xiàng)目.
當(dāng)然, spec 文件可以寫的很複雜, 不過, 你應(yīng)知道我講啥了吧?
--- 關(guān)于 spec 的撰寫, 我這裡同樣略過....
哈~~~ 被我打敗了嗎? 呵~~~~~~ take it easy, 只講原理, okay?

當(dāng)你有了一個(gè) tarball 之后, 你就可另行撰寫 rpm spec,
然后用 rpmbuild 指令, 完成 spec 所定議的每一道指令.
(其實(shí)跟你自己跑 make 差不多, 只是更為自動(dòng)化而已...)
最終, 可以生成 binary rpm 格式的文件.
然后, 再用 rpm 命令按照 spec 的定議將所有文件安裝好, 并修改數(shù)據(jù)庫, 完成一切.
這樣, 你之前用 tarball 裝的東西不會(huì)少掉, 但是數(shù)據(jù)庫就存有關(guān)于軟件的所有資訊了!
豈不美哉?!? ^_^

hold on...
is it good enough? darling?
我們必須承認(rèn): 人心是不足的!
是啊, 有了 RPM 不見的就能解決所有軟件問體.
裝過 RPM 的朋友, 一定都碰過 dependence 的問題吧?
唉, 這部份, 我真不想講了, 現(xiàn)等你對(duì) library 有了概念, 再回來探討好了.
只能說, RPM 只是好心, 但不見的有好報(bào)啦... ?
這心境, 跟我們常在論壇回答問題還遭白眼的情形差不多的.... 唉... 無奈... >;_<
唉... 那就不說了吧.

除了 dependence 之外, RPM 還有哪些不足呢?
嗯. 首先, 人們拿到的大都是 binary RPM, 也就是 spec 已定死, 編譯已完成的 RPM.
就算下載回來, 也無從改起.
--- 軟件之所以進(jìn)步, 就是因?yàn)槿藗儠?huì)隨時(shí)隨地將存在的問題解決掉!
于是, 有了 Source RPM 的存在.
說穿了, source RPM 只不過是包了 tarball 跟 rpm spec 這兩樣?xùn)|西而已.
只要將 src.rpm 裝好, 然后你就可修改 spec, 也可打開 tarball 修改裡面的代碼及 Makefile.
修改好之后, 再次將之編譯成為 binary RPM 就行了.
這給了人們很大的彈性, 又不失 RPM db 的便利.
假如你找不到滿意的 binary RPM 的話, 那就找 source RPM 吧. 你會(huì)喜歡它的!
而且, 就算沒有 source RPM, 現(xiàn)在很多 tarball 裡面, 作者們也都主動(dòng)提供了 spec .
如此, 人們就可以隨時(shí)地自己建出合用的 binary RPM 了.

嗯. RPM 就是好啊!
但是, 每個(gè) binary RPM 都是零散的, 我們常要為了裝一個(gè)軟件, 而順藤摸瓜的抓了一堆 RPM 回來.
(這裡我一定要提醒版本的問題, 因?yàn)檫@會(huì)扯上軟件環(huán)境, 也就是前面提到的惱人的 dependence 問題.
然而, 平心而論, 凡是軟件都會(huì)碰到 dependence , 只是 RPM 把關(guān)工作做得嚴(yán)謹(jǐn)而已.)
--- 軟件之所以進(jìn)步, 就是因?yàn)槿藗儠?huì)隨時(shí)隨地將存在的問題解決掉!
是的, 于是有了 package server 的概念.
也就是, 從此, 我們的軟件不再需要抓到自己的機(jī)器去了.
這一切都拜網(wǎng)絡(luò)所賜: 我們將所有軟件都集中放到 server 去, 分們別類進(jìn)行管理.
我們只需在 client 端裝個(gè) fron end 工具, 將一個(gè)或多個(gè) server 的地址設(shè)上去.
從此, 每一臺(tái)機(jī)器都有了源源不絕的 RPM 或 src.rpm .
現(xiàn)在較新發(fā)行的 Linux 版本, 都全部採用這一方式來管理軟件了.
當(dāng)然, 有些版本不見得是用 RPM 啦(如 debian, geento)... 不過原理卻是一樣的.
比方你用最新版的 redhat/fedora,
只要跑 yum update 就會(huì)將當(dāng)前的軟件全更新了; yum install 就可安裝指定的軟件.
若還需要其他依存軟件, 也自動(dòng)一一下載并完成安裝.
甚至還可以將整個(gè)系統(tǒng)進(jìn)行升級(jí)!

呵... 是的. 目前來說, 較之以前的 tarball 年代, 軟件的管理工作已經(jīng)相當(dāng)便捷而成熟了.
希望本文, 能助大家對(duì)軟件管理(Package Management)有一簡單的了解.
若你不想深究原理的話, 那你也不需苦惱, 只須乖乖記著如下的忠告就行:
1) 能用 yum, apt, urpmi, yast 等先進(jìn)的軟件管理工具, 就盡量用吧.
2) 能用 rpm 就盡量用吧, 但要注意版本要一至.
3) 要是不行, 還有 source rpm 可用.
4) 真的沒法子, 那才用 tarball .
5) 當(dāng)然, 你自己能寫代碼的話, 那就更不用愁了!

再一次:
--- 軟件之所以進(jìn)步, 就是因?yàn)槿藗儠?huì)隨時(shí)隨地將存在的問題解決掉!
我相信, 軟件管理的進(jìn)步還是會(huì)持續(xù)下去的, 日后會(huì)面臨甚麼問題? 或得到甚麼解決? 現(xiàn)在不需過份擔(dān)心.
盡管抱著積極樂觀的態(tài)度去迎接將來就是了!

祝大家:
??????? 中秋快樂!


netman
2005/09/10 于臺(tái)南

rpm包與tar包到底有何區(qū)別？