要了解 tarball 與 rpm 的差別, 不妨先從軟件的產生開始談吧.
簡單來說, 現今的電腦, 之所以能運作, 是因為它會處理 0 跟 1 , 但問題卻也是只能處理 0 跟 1 .
因此, 要讓電腦能執行的軟體程式, 必需以 0 跟 1 的二進位(binary)格式出現, 我們稱之為---執行碼(executable).
而且, 不同的 CPU 所執行的格式都不盡相同, 我們稱之為硬件平台(platform).
以個人電腦來說, 最常見的硬件平台多是 Intel 公司設計(或兼容)的 CPU, 常稱為 i386 或 x86 .
然而, 二進位格式卻造成程式設計師撰寫程式的難度太高了! (呵, 別懷疑, 早期的確如此~~)
聰明的人們, 於是選用了別種較為易懂的方式來轉寫, 也就是我們常說的"程式語言"了.
我們稱這些寫用程式語言撰寫的代碼為---源代碼(source code).程式語言很多, 在 Unix/Linux 世界裡, C 語言是最傳統也最常用的程式語言.
在這基礎上, 我們需知道如下事實:
1) 我們可用的程式語言很多種.
2) 可供執行的硬件平台也很多種.
3) 用程式語言寫好的源代碼並不會自動變成二進位格式.
這就是"編譯器(compiler)"上場的時候了. 換句話來說:
--- 寫好的源代碼必須針對不同的硬件平台進行編譯才能能產生執行碼.
不同語言的源代碼及不同硬件平台均需要不同的編譯器來執行這項工作.
要是你用 C 來寫源代碼的話, 那最常見的編譯器就是 C Compiler, 簡稱為 cc .
然而 cc 也有很多不同的版本, 功能效能及作業平台或有所不同.
Linux 最常見的就是 GNU 的 C Compiler, 簡稱為 gcc .
當你寫好 c code, 同時裝好了 gcc, 那你就可執行 gcc 編譯出執行碼.
然後, 再將編好的執行碼複制到相關路逕, 人們便可在這台機器上執行該程式了.
我這裡暫不介紹如何寫 C 代碼, 也不介紹怎麼跑 gcc, 有待大家自己學習.
事實上, 越複雜的程式, 代碼越長, 也越難設計與為護, 而 gcc 可選用的參數也越多.
我這裡也暫時不介紹函式庫(library)的概念了, 但其實這方面還可大書特書的.
我非常建議讀者搞懂函式庫的概念, 尤其是靜態(static)與動態(dynamic)函式調用方式的差別.
因為這會扯上執行環境的依賴性及程式的移植性, 也就是所謂的---軟件依存關系(dependence).
嗯, 還是先請大家自己琢磨吧, 要是日後有機會的話, 再回來跟大家介紹好了.
到此為止, 相信大家已經知道軟件是怎麼蹦出來的了!
然而, 如下問題, 請大家不妨老實作答:
1) 你會寫源代碼嗎?
2) 你會得執行 gcc 及相關參數嗎?
(呵... 坦白講, 我就不很懂了!)
而且, 就算你懂了, 那:
3) 你願意每次安裝軟件都敲上百行的 gcc 命令嗎?
(呵... 同樣的, 我也不願意!)
將心比心, 那些普通電腦使用者呢? 他們又作何感想呢?
難道擁抱軟件非要如此折騰不可?
這裡, 請你先記著這句話:
--- 軟件之所以進步, 就是因為人們會隨時隨地將存在的問題解決掉!
前面提及的, 從二進位撰寫改為從源代碼撰寫, 就是一個很了不起的進步. 更別提古老的"打孔卡"年代了!
然而, 這進步是不夠的... 人們並不滿足啊~~~
於是, 就有了 make 這個程式出現了.
簡單而言, make 就是讀入一份預先編寫好的 Makefile, 然後自動的幫我們完成所有的編譯工作.
具體的 Makefile 格式, 我這裡也暫時略過, 還是留給大家自行學習. (我這裡只想講概念)
能理解 Makefile 帶來的進步很重要, 因為後面提到的 rpm spec 也是源於相同的理念.
從此, 我們只需跑幾個簡單的 make 指令, 就能代替過往上百成千行的 gcc 命令了!
what a wonderful thing!
okay, 不得不承認 Makefile 曾經為人們帶來過一段時間的滿意.
it's good, but not good enough!
還有啥不滿足呢?
隨著電腦的普及, 軟件的散播速度也大大的提高了.
且, 面臨的各種不同的執行環境差異也越來越廣.
人們慢慢發現: 單一的 Makefile 沒法滿足所有環境的需求!
怎麼辦?
呵.... 回到前面的老話:
--- 軟件之所以進步, 就是因為人們會隨時隨地將存在的問題解決掉!
於是, 聰明的人們, 開始撰寫一些環境偵查工具, 大多是一些 script 語言(shell, perl 等等),
讓使用者可以先執行之, 然後按不同的偵查結果自動修改 Makefile.
同時, 用心的作者, 還允許使用者透過各種參數, 來指定特殊的需求.
yeah... perfect?!
Nooooooooooooooot yet!!
又怎了?
唉呀, 親愛的朋友啊, 要是我不講, 你怎知道原來還可以這樣玩呢?
更何況那些快快樂樂只想跑應用的普通用戶呢?! 就算我這樣講, 對他們來說, 還是一頭霧水啊~~~
don't worry!
--- 軟件之所以進步, 就是因為人們會隨時隨地將存在的問題解決掉!
於是, 作者一不做二不休, 乾脆將所有步驟及可能的環境需求與操作, 寫成文檔, 讓使用者慢慢讀就是了.
這, 就是 README, INSTALL 這類文檔存在的意意了!
呵... 到這裡, 你是否豁然開朗了? 原來, 我們之前常看到人們裝軟件都是如此跑的:
1) less README INSTALL
2) ./configure
3) make
4) make install
只要你能理解前面所講的, 那, 你就能了解為何都是這幾個步驟了... ^_^
這, 就是人們常說的"源代碼安裝"方式了, 或稱為 tarball .
(嗯, tarball 其實還要扯上 tar 與 gzip/gunzip 等程式, 我這裡也暫時不談了.)
然而, 問題真的解決了嗎?
你以為真的從此就天下太平了嗎?
若你認為滿足的話, 那我再來問你幾個問題:
1) 你知道系統一共裝了哪些軟件嗎?
2) 它們是誰提供的? 版本為何?
3) 你知道剛剛裝的軟件裝哪去了?
4) 你知道自從安裝後, 有哪些文件被修改過?
5) 這個軟件要依存哪些其他軟件嗎?
6) 又有哪些軟件依存你這個軟件呢?
7) 你可以放心的移除它或升級它嗎?
8) 你知道其他夥伴又裝了哪些改了哪些嗎?
9) 你知道這每一台機器的軟件狀況嗎?
9) 若你要將職務交接給別人, 你能交代清楚嗎?
10) 要是你從別人接管過來呢?
等等又等等....
這些一直以來都是軟件管理上必答的問題. 然而, 你的答案又有幾多呢?!
別跟我說, 你可以耍賴不答哦. 要是你自己的系統, 隨便你怎搞都行.
但, 要是你是每月都領別人薪水的話, 這些基本問題答不出來, 你還好意思拿? 你還有臉說要加薪?
嗯????
你在冒冷汗了嗎? 朋友?
呵... 不用内疚啦, 不只是你, 很多人都碰到同樣的問題啊...
--- 軟件之所以進步, 就是因為人們會隨時隨地將存在的問題解決掉!
那, 請問, 接下來, 換作是你的話, 怎麼解決上述那些問題?
1) 用腦記?
2) 用筆寫?
3) 請秘書?
4) 置之不理?
呵... 朋友, 別忘了你是個聰明的 IT 專業人員哦~~~
5) 寫成電子文檔?
夠了嗎? 當然不夠!
6) 做成數據庫(database)?
yeeeeeaaaaahhhhhhhhhhhh! Bingo! 你中獎了!
你從事 IT 這麼久了, 難道沒想到: 凡是要備案查詢的東西就交給數據庫吧!
是的! 我們也可用數據庫來追蹤及管理我們的軟件資訊啊, 不是嗎?
事實的確就是如此!
不過, 你會寫數據庫嗎? 就算會寫, 能否用來管我們的軟件?
(老實又坦白的說: 老子就不會!)
怎樣? 難道不可用別人的嗎?
呵.... 是的: 用別人的勞動成果 --- 這跟你不用自己寫源代碼的道理是一樣的!
那, 用誰的呢?
其實答案已經呼之欲出了 --- Redhat Package Management(RPM) 就是其中佼佼者.
這個詞中的 Package 指的就是我們裝在電腦上的軟件了.
(Package Managemnet 跟 Software Management 其實是有差別的, 我們這裡談的是 package .)
RPM 有啥能耐呢?
說穿了, 就是一個 database 而已.
有了它, 前面問到的關於軟件管理的問題全部都可以輕鬆就回答出來了.
呵... 關於 rpm 指令的運用, 我這裡同樣略過, 只講原理, okay?
okay!
那麼, rpm db 又怎麼冒出來的呢?
嗯..... 這個就要扯上 rpm spec 了.
還記的前面提到的 Makefile 嗎?
若你記得 Makefile 可以自動跑 gcc 的話,
那麼一個簡單的 rpm spec 就是幫你自動跑 configure 跟 make 那些指令!
然後, 再額外增加了數據庫的資料項目.
當然, spec 文件可以寫的很複雜, 不過, 你應知道我講啥了吧?
--- 關於 spec 的撰寫, 我這裡同樣略過....
哈~~~ 被我打敗了嗎? 呵~~~~~~ take it easy, 只講原理, okay?
當你有了一個 tarball 之後, 你就可另行撰寫 rpm spec,
然後用 rpmbuild 指令, 完成 spec 所定議的每一道指令.
(其實跟你自己跑 make 差不多, 只是更為自動化而已...)
最終, 可以生成 binary rpm 格式的文件.
然後, 再用 rpm 命令按照 spec 的定議將所有文件安裝好, 並修改數據庫, 完成一切.
這樣, 你之前用 tarball 裝的東西不會少掉, 但是數據庫就存有關於軟件的所有資訊了!
豈不美哉?! ^_^
hold on...
is it good enough? darling?
我們必須承認: 人心是不足的!
是啊, 有了 RPM 不見的就能解決所有軟件問體.
裝過 RPM 的朋友, 一定都碰過 dependence 的問題吧?
唉, 這部份, 我真不想講了, 現等你對 library 有了概念, 再回來探討好了.
只能說, RPM 只是好心, 但不見的有好報啦...
這心境, 跟我們常在論壇回答問題還遭白眼的情形差不多的.... 唉... 無奈... >;_<
唉... 那就不說了吧.
除了 dependence 之外, RPM 還有哪些不足呢?
嗯. 首先, 人們拿到的大都是 binary RPM, 也就是 spec 已定死, 編譯已完成的 RPM.
就算下載回來, 也無從改起.
--- 軟件之所以進步, 就是因為人們會隨時隨地將存在的問題解決掉!
於是, 有了 Source RPM 的存在.
說穿了, source RPM 只不過是包了 tarball 跟 rpm spec 這兩樣東西而已.
只要將 src.rpm 裝好, 然後你就可修改 spec, 也可打開 tarball 修改裡面的代碼及 Makefile.
修改好之後, 再次將之編譯成為 binary RPM 就行了.
這給了人們很大的彈性, 又不失 RPM db 的便利.
假如你找不到滿意的 binary RPM 的話, 那就找 source RPM 吧. 你會喜歡它的!
而且, 就算沒有 source RPM, 現在很多 tarball 裡面, 作者們也都主動提供了 spec .
如此, 人們就可以隨時地自己建出合用的 binary RPM 了.
嗯. RPM 就是好啊!
但是, 每個 binary RPM 都是零散的, 我們常要為了裝一個軟件, 而順藤摸瓜的抓了一堆 RPM 回來.
(這裡我一定要提醒版本的問題, 因為這會扯上軟件環境, 也就是前面提到的惱人的 dependence 問題.
然而, 平心而論, 凡是軟件都會碰到 dependence , 只是 RPM 把關工作做得嚴謹而已.)
--- 軟件之所以進步, 就是因為人們會隨時隨地將存在的問題解決掉!
是的, 於是有了 package server 的概念.
也就是, 從此, 我們的軟件不再需要抓到自己的機器去了.
這一切都拜網絡所賜: 我們將所有軟件都集中放到 server 去, 分們別類進行管理.
我們只需在 client 端裝個 fron end 工具, 將一個或多個 server 的地址設上去.
從此, 每一台機器都有了源源不絕的 RPM 或 src.rpm .
現在較新發行的 Linux 版本, 都全部採用這一方式來管理軟件了.
當然, 有些版本不見得是用 RPM 啦(如 debian, geento)... 不過原理卻是一樣的.
比方你用最新版的 redhat/fedora,
只要跑 yum update 就會將當前的軟件全更新了; yum install 就可安裝指定的軟件.
若還需要其他依存軟件, 也自動一一下載並完成安裝.
甚至還可以將整個系統進行升級!
呵... 是的. 目前來說, 較之以前的 tarball 年代, 軟件的管理工作已經相當便捷而成熟了.
希望本文, 能助大家對軟件管理(Package Management)有一簡單的了解.
若你不想深究原理的話, 那你也不需苦惱, 只須乖乖記著如下的忠告就行:
1) 能用 yum, apt, urpmi, yast 等先進的軟件管理工具, 就盡量用吧.
2) 能用 rpm 就盡量用吧, 但要注意版本要一至.
3) 要是不行, 還有 source rpm 可用.
4) 真的沒法子, 那才用 tarball .
5) 當然, 你自己能寫代碼的話, 那就更不用愁了!
再一次:
--- 軟件之所以進步, 就是因為人們會隨時隨地將存在的問題解決掉!
我相信, 軟件管理的進步還是會持續下去的, 日後會面臨甚麼問題? 或得到甚麼解決? 現在不需過份擔心.
盡管抱著積極樂觀的態度去迎接將來就是了!
祝大家:
中秋快樂!
netman
2005/09/10 於台南
