鳥哥的linxu私房菜讀書筆記
前言：
Linux上軟件的安裝可以以原始碼的方式來安裝軟件，也就是利用廠商釋出的 Tarball 來進行軟件的安裝。不過，你應該很容易發現，那就是每次安裝軟件都需要偵測操作系統與環境、設定編譯參數、實際的編譯、最后還要依據個人喜好的方式來安裝軟件到定位。這過程是真的很麻煩的，而且對於不熟悉整個系統的朋友來說，還真是累人啊！
那有沒有想過，如果我的Linux系統與廠商的系統一模一樣，那么在廠商的系統上面編譯出來的執行檔，自然也就可以在我的系統上面跑啰！也就是說，廠商先在他們的系統上面編譯好了我們用戶所需要的軟件，然后將這個編譯好的可執行的軟件直接釋出給用戶來安裝，如此一來，由於我們本來就使用廠商的 Linux distribution ，所以當然系統 (硬件與操作系統) 是一樣的，那么使用廠商提供的編譯過的可執行文件就沒有問題啦！ 說的比較白話一些，那就是利用類似 Windows 的安裝方式，由程序開發者直接在已知的系統上面編譯好，再將該程序直接給用戶來安裝，如此而已。
那么如果在安裝的時候還可以加上一些與這些程序相關的信息，將他建立成為數據庫，那么就可以進行安裝、反安裝、 升級不驗證等等的相關功能啰 (類似 Windows 底下的『新增移除程序』)？確實如此，在 Linux 上面至少就有兩種常見的這方面的軟件管理員，分別是RPM與Debian的dpkg。我們的CentOS主要是以RPM為主但也不能不知道dpkg啦！所以底下就來約略介紹一下這兩個玩意兒。
Linux 界的兩大主流: RPM 和 DPKG
由於自由軟件的蓬勃發展，加上大型 Unix-Like 主機的強大效能，讓很多軟件開發者將他們的軟件使用Tarball來釋出。后來 Linux 發展起來后，由一些企業或社群將這些軟件收集起來制作成為distributions以發布這好用的Linux操作系統。但后來發現到，這些distribution的軟件管理實在傷腦筋，如果軟件有漏洞時，又該如何修補呢？使用 tarball 的方式來管理嗎？又常常不曉得到底我們安裝過了哪些程序？因此，一些社群不企業就開始思考Linux的軟件管理方式。
如同剛剛談過的方式，Linux開發商先在固定的硬件平台不操作系統平台上面將需要安裝戒升級的軟件編譯好，然后將這個軟件的所有相關檔案打包成為一個特殊格式的檔案，在這個軟件檔案內還包含了預先偵測系統不相依軟件的腳本，並提供記載該軟件提供的所有檔案信息等。最終將這個軟件檔案釋出。客戶端取得這個檔案后，只要透過特定的指令來安裝，那么該軟件檔案就會依照內部的腳本來偵測相依的前驅軟件是否存在，若安裝的環境符合需求，那就會開始安裝，安裝完成后還會將該軟件的信息寫入軟件管理機制中，以達成未來可以進行升級、移除等動作呢。
目前在 Linux 界軟件安裝方式（也就是剛才所說的distribution檔案，通過這個特殊的指令讀取檔案信息並安裝、卸載等關聯linux軟件）最常見的有兩種，分別是:
dpkg:
Debian Packager的縮寫。
這個機制最早是由Debian Linux社群所開發出來的，透過dpkg的機制，Debian提供的軟件就能夠簡單的安裝起來，同時還能提供安裝后的軟件信息，實在非常不 錯。只要是衍生於Debian的其他Linux distributions大多使用dpkg 這個機制來管理軟件的，包括B2D,Ubuntu等等。
rpm:
Red Hat Package Manager的縮寫。
這個機制最早是由 Red Hat 這家公司開發出來的，后來實在很好用，因此很多 distributions 就使用這個機制來作為軟件安裝的管理方式。包拪 Fedora, CentOS, SuSE 等等知名的開發商都是用這種方式。
如前所述，不論dpkg/rpm這些機制或多或少都會有軟件屬性相依的問題，那該如何解決呢？其實前面不是談到過每個軟件檔案都有提供相依屬性的檢查嗎？那么如果我們將相依屬性的數據做成列表，等到實際軟件安裝時，若發生有相依屬性的軟件狀況時，例如安裝A需要先安裝B與C而安裝B則需要安裝D與E時那舉當你要安裝A，透過相依屬性列表，管理機制自動去取得B,C,D, E來同時安裝，不就解決了屬性相依的問題嗎？
目前新的Linux開發商都有提供這樣的『在線升級』機制，透過這個機制，原版光盤就只有第一次安裝時需要用到而已，其他時候只要有網絡，你就能夠取得原本開發商所提供的任何軟件了呢！在dpkg管理機制上就開發出APT的在線升級機制，RPM則依開發商的不同，有Red Hat系統的yum，SuSE系統的Yast Online Update (YOU)， Mandriva 的urpmi軟件等。
什么是RPM與SRPM
RPM全名是『 RedHat Package Manager 』簡稱則為RPM啦！顧名思義，當初這個軟件管理的機制是由Red Hat這家公司發展
出來的。RPM是以一種數據庫記錄的方式來將你所需要的軟件安裝到你的Linux系統的一套管理機制。
他最大的特點就是：將你要安裝的軟件先編譯過，並且打包成為RPM機制的包裝檔案，透過包裝好的軟件里頭默認的數據庫記錄，記錄這個軟件要安裝的時候必須具備的相依屬性軟件，當安裝在你的Linux主機時，RPM會先依照軟件里頭的數據查詢Linux主機的相依屬性軟件是否滿足，若滿足則予以安裝，若不滿足則不予安裝（這個並不會自動安裝軟件依賴的軟件，只會檢查是否安裝了該軟件依賴的軟件，如果在linux相關數據庫中查詢到沒有安裝相關依賴軟件，就不會安裝這個軟件了）。那么安裝的時候就將該軟件的信息整個寫入RPM的數據庫中，以便未來的查詢、驗證與反安裝！這樣一來的優點是：
1. 由於已經編譯完成並且打包完畢，所以軟件傳輸與安裝上很方便 (不需要再重新編譯)；
2. 由於軟件的信息都已經記錄在Linux主機的數據庫上，很方便查詢、升級與反安裝;
但是這也造成些許的困擾。由於RPM檔案是已經包裝好的數據也就是說，里面的數據已經都『編譯完成』了！所以，該軟件檔案幾乎只能安裝在原本硬件的硬件與操作系統版本中。也就是說，你的主機系統環境必須要與當初建立這個軟件檔案的主機環境相同才行！ 舉例來說，rp-pppoe這個ADSL 撥接軟件，他必須要在ppp這個軟件存在的環境下才能進行安裝！如果你的主機幵沒有ppp這個軟件，那么很抱歉，除非你先安裝ppp否則rp-pppoe就是不讓你安裝的 (當然你可以強制安裝，但是通常都會有點問題發生就是了！)。
所以，通常不同的distribution所釋出的RPM檔案，並不能用在其他的distributions上。舉例來說，Red Hat釋出的RPM檔案，通常無法直接在SuSE上面進行安裝的。更有甚者，相同distribution的不同版本之間也無法互通，例如CentOS 4.x的RPM檔案就無法直接套用在CentOS 5.x！因此，這樣可以發現這些軟件管理機制的問題是：
1. 軟件檔案安裝的環境必須不打包時的環境需求一致或相當；
2. 需要滿足軟件的相依屬性需求（如果檢查到沒有安裝相依賴的軟件，就裝不上這個軟件了）；
3. 反安裝時需要特別小心，最底層的軟件不可先移除，否則可能造成整個系統的問題！
那怎么辦？如果我真的想要安裝其他distributions提供的好用的RPM軟件檔案時？ 還好，還有SRPM這個東西！SRPM是什么呢？顧名思義，他是Source RPM的意思，也就是這個RPM檔案里面含有原始碼哩！特別注意的是，這個SRPM所提供的軟件內容『並沒有經過編譯』，他提供的是原始碼喔！通常SRPM的擴展名是以 ***.src.rpm 這種格式來命名的。不過，既然SRPM提供的是原始碼，那么為什么我們不使用Tarball直接來安裝就好了？這是因為SRPM雖然內容是原始碼，但是他仍然含有該軟件所需要的相依性軟件說明、以及所有RPM檔案所提供的數據。同時，他與RPM不同的是，他也提供了參數配置文件 (就是configure與makefile)。所以，如果我們下載的是SRPM，那
么要安裝該軟件時，你就必須要：
1.先將該軟件以 RPM 管理的方式編譯，此時SRPM 會被編譯成為RPM檔案；
2.然后將編譯完成的RPM檔案安裝到Linux系統當中。
怪了，怎么SRPM這么麻煩吶！還要重新編譯一次，那舉我們直接使用RPM來安裝不就好了？通常一個軟件在釋出的時候，都會同時釋出該軟件的RPM與SRPM 。我們現在知道 RPM 檔案必須要在相同的Linux環境下才能夠安裝，而SRPM既然是原始碼的格式，自然我們就可以透過修改SRPM內的參數配置文件，然后重新編譯產生能適合我們Linux環境的RPM檔案，如此一來，不就可以將該軟件安裝到我們的系統當中，而不必與原作者打包的Linux環境相同了？這就是SRPM的用處了！
| 文件格式 | 檔名格式 | 直接安裝與否 | 內含程序類型 | 可否修改參數並編譯 |
| RPM | xxx.rpm | 可 | 已編譯 | 不可 |
| SRPM | xxx.src.rpm | 不可 | 未編譯之原始碼 | 可 |
Tips:
為何說CentOS是『社群維護的企業版』呢？Red Hat公司的RHEL釋出后，連帶會將SRPM釋出。社群的朋友就將這些SRPM收集起來並重新編譯成為所需要的軟件， 再重復釋出成為CentOS，所以才能號稱與Red Hat的RHEL企業版同步啊！真要感謝SRPM哩！如果你想要理解CentOS是如何編譯一支程序的，也能夠透過學習SRPM內含的編譯 參數，來學習的啊！
什么是 i386, i586, i686, noarch, x86_64
從上面的說明，現在我們知道RPM與SRPM 的格式分別為：
xxxxxxxxx.rpm <==RPM 的格式，已經經過編譯並包裝完成的rpm檔案；
xxxxx.src.rpm <==SRPM 的格式，包含未編譯的原始碼信息。
那么我們怎么知道這個軟件的版本、適用的平台、編譯釋出的次數呢？只要透過檔名就可以知道了！例如 rp-pppoe-3.1-5.i386.rpm
這的檔案的意義為：
rp-pppoe-3.1-5.i386.rpm
軟件名稱-軟件的版本信息-釋出的次數-適合的硬件平台-擴展名，除了后面適合的硬件平台不擴展名外，主要是以『-』來隔開各個部分，這樣子可以很清楚的發現該軟件的名稱、版本信息、打包次數與操作的硬件平台！好了，來談一談每個不同的地方吧：
1.軟件名稱：
當然就是每一個軟件的名稱了！上面的范例就是rp-pppoe 。
2.版本信息：
每一次更新版本就需要有一個版本的信息，否則如何知道這一版是新是舊？這里通常又分為主版本跟次版本。以上面為例，主版本為 3 ，在主版本的架構下更新部分原始碼內容，而釋出一個新的版本，就是次版本啦！以上面為例，就是1啰！
3.釋出版本次數：
通常就是編譯的次數啦！那么為何需要重復的編譯呢？這是由於同一版的軟件中，可能由於有某些bug或者是安全上的顧慮，所以必須要進行小幅度的patch或重設一些編譯參數。設定完成之后重新編譯並打包成RPM檔案！因此就有不同的打包數出現了！
4.操作硬件平台：
這是個徆很玩的地方，由於RPM可以適用在不同的操作平台上，但是不同的平台設定的參數還是有所差異性！ 並且，我們可以針對比較高階的CPU來進行優化參數的設定，這樣才能夠使用高階CPU所帶來的硬件加速功能。所以就有所謂的i386, i586,i686,x86_64與noarch等的文件名出現了！
受惠於目前x86系統的支持方面，新的CPU都能夠執行舊型 CPU 所支持的軟件，也就是說硬件方面都可以向下兼容的，因此最低等級的i386軟件可以安裝在所有的x86硬件平台上面，不論是32位還是64位。但是反過來說就不行了。舉例來說，目前硬件大多是64位的等級，因此你可以在該硬件上面安裝x86_64或i386等級的RPM軟件。但在你的舊型主機，例如PIII/P-4 32位機器上面，就不能夠安裝x86_64的軟件！
根據上面的說明，其實我們只要選擇i386版本來安裝在你的x86硬件上面就肯定沒問題。但是如果強調效能的話，還是選擇搭配你的硬件的RPM檔案吧！畢竟該軟件才有針對你的CPU硬件平進行過參數優化的編譯嘛！