原始碼與 Tarball 套件管理員zz

Tarball 的管理與建議：
 好了！在我們知道了原始碼的相關資訊之後，再來要瞭解的自然就是如何使用具有原始碼的 Tarball 來建立一個屬於自己的套件囉！從前面幾個小節的說明當中，我們曉得其實 Tarball 的安裝是可以跨平台的，因為 C 語言的程式碼在各個平台上面是可以共通的， 只是需要的編譯器可能並不相同而已。例如 Linux 上面用 gcc 而 Windows 上面也有相關的 C 編譯器啊～所以呢，同樣的一組原始碼，既可以在 Fedora Linux 上面編譯，也可以在 SuSE Linux 上面編譯，當然，也可以在大部分的 Unix 平台上面編譯成功的！

所以囉， Tarball 原始碼程式應該可以在大部分的環境底下安裝成功的！舉例來說，鳥哥在上面幾個小節所提供的 C 程式是在 Fedora Core 4 及 Red Hat 9 上面測試編譯的，那麼您可以下載之後在自己的 Linux 環境下測試看看，我想，每個人應該都可以順利的編譯成功的才是！因為 C 的語法是沒有不一樣的啊！ ^_^

如果萬一沒有編譯成功怎麼辦？很簡單啊，透過修改小部分的程式碼( 通常是因為很小部分的異動而已 )就可以進行跨平台的移植了！也就是說，剛剛我們在 Linux 底下寫的程式『理論上，是可以在 Windows 上面編譯的！』這就是原始碼的好處啦！所以說，如果朋友們想要學習程式語言的話， 鳥哥個人是比較建議學習『具有跨平台能力的程式語言』，例如 C 就是很不錯的一個！

唉啊！又扯遠了～趕緊拉回來繼續說明我們的 Tarball 啦！

---

使用原始碼管理套件所需要的基礎套件

從原始碼的說明我們曉得要製作一個 binary 執行檔需要很多咚咚的呢！這包括底下這些基礎的套件：

• gcc 或 cc 等 C 語言編譯器( compiler )：
  這是一定要的啦！要將原始碼編譯成為可執行的 binary 才行，所以當然就需要編譯器囉！在 Linux 上面用的當然就是 GNU 發展的 gcc 這個超好用的免費的 C 編譯器啦！並且，很多在 Linux 平台上面發展的套件的原始碼，原本就是以 gcc 為底來設計的呢。


• make 及 autoconfig 等套件：
  一般來說，以 Tarball 方式釋出的套件當中，為了簡化編譯的行程，通常都是配合前幾個小節提到的 make 這個指令來依據目標檔案的相依性而進行編譯。但是我們也知道說 make 需要 makefile 這個檔案的規則，那由於不同的系統裡面可能具有的基礎套件環境並不相同， 所以就需要偵測使用者的作業環境，好自行建立一個 makefile 檔案。這個自行偵測的小程式也必須要藉由 autoconfig 這個相關的套件來輔助才行。


• 需要 Kernel 提供的 Library 以及相關的 Include 檔案：
  從前面的原始碼編譯過程，我們曉得函式庫( library )的重要性，同時也曉得有 include 檔案的存在。很多的套件在發展的時候都是直接取用系統核心提供的函式庫與 include 檔案的，這樣才可以與這個作業系統相容啊！尤其是在『 驅動程式方面的套件 』，例如網路卡、音效卡、USB 等驅動程式在安裝的時候，常常是需要核心提供的相關資訊的。在 Red Hat 的系統當中 ( 包含 Fedora 等系列 ) ，這個核心相關的功能通常都是被包含在 kernel-source 或 kernel-header 這些套件名稱當中，所以記得要安裝這些套件喔！

雖然 Tarball 的安裝上面相當的簡單，如同我們前面幾個小節的例子，只要順著開發商提供的 README 與 INSTALL 檔案所載明的步驟來進行，安裝是很容易的。但是我們卻還是常常會在 BBS 或者是新聞群組當中發現這些留言：『我在執行某個程式的偵測檔案時，他都會告訴我沒有 gcc 這個套件，這是怎麼回事？』還有：『我沒有辦法使用 make 耶！這是什麼問題？』呵呵！ 這就是沒有安裝上面提到的那些基礎套件啦！

咦！為什麼使用者不安裝這些套件啊？呵呵！這是因為目前的 Linux distribution 大多已經偏向於桌上型電腦的使用，他們希望使用者能夠按照廠商自己的希望來安裝相關的套件即可， 所以通常『預設』是沒有安裝 gcc 或者是 make 等套件的。所以啦，如果您希望未來可以自行安裝一些以 Tarball 方式釋出的套件時，記得請自行挑選想要安裝的套件名稱喔！例如在 Fedora 或者是 Red Hat 當中記得選擇 Software Development 以及 Kernel Source Development 等相關字眼的群集呢。

那萬一我已經安裝好一部 Linux 主機，但是使用的是預設值所安裝的套件，所以沒有 make, gcc 等咚咚，該如何是好？呵呵！問題其實不大啦，目前使用最廣泛的 Fedora 或者是 Red Hat 大多是以 RPM ( 下一章會介紹 ) 來安裝套件的，所以，您只要拿出當初安裝 Linux 時的原版光碟，然後以下一章介紹的 RPM 來一個一個的加入到您的 Linux 主機裡面就好啦！很簡單的啦！

---

Tarball 安裝的基本步驟

我們提過以 Tarball 方式釋出的套件是需要重新編譯可執行的 binary file 的。而 Tarball 是以 tar 這個指令來打包與壓縮的檔案，所以啦，當然就需要先將 Tarball 解壓縮，然後到原始碼所在的目錄下進行 makefile 的建立，再以 make 來進行編譯與安裝的動作啊！所以整個安裝的基礎動作大多是這樣的：

1. 將 tarball 檔案在 /usr/local/src 目錄下解壓縮；
2. 進入新建立的目錄底下，去查閱 INSTALL 與 README 等相關檔案內容( 很重要的步驟！ )；
3. 根據 INSTALL/README 的內容察看並安裝好一些相依的套件( 非必要 )；
4. 以自動偵測程式( configure 或 config )偵測作業環境，並建立 Makefile 這個檔案；
5. 以 make 這個程式並使用該目錄下的 Makefile 做為他的參數設定檔，來進行 make ( 編譯或其他 )的動作；
6. 以 make 這個程式，並以 Makefile 這個參數設定檔，依據 install 這個標的( target )的指定來安裝到正確的路徑！

注意到上面的第二個步驟，通常在每個軟體在釋出的時候，都會附上 INSTALL 或者是 README 這種檔名的說明檔，這些說明檔請『確實詳細的』 閱讀過一遍，通常這些檔案會記錄這個軟體的安裝要求、軟體的工作項目、 與軟體的安裝參數設定及技巧等，只要仔細的讀完這些檔案，基本上，要安裝好 tarball 的檔案，都不會有什麼大問題囉。至於 makefile 在製作出來之後，裡頭會有相當多的標的( target )，最常見的就是 install 與 clean 囉！通常『make clean』代表著將目標檔( object file )清除掉，『make』則是將原始碼進行編譯而已。 注意喔！編譯完成的可執行檔與相關的設定檔還在原始碼所在的目錄當中喔！因此，最後要進行『make install』來將編譯完成的所有咚咚都給他安裝到正確的路徑去，這樣就可以使用該套件啦！

OK！我們底下約略提一下大部分的 tarball 軟體之安裝的指令下達方式：

1. ./configure
   這個步驟就是在建立 Makefile 這的檔案囉！通常程式開發者會寫一支 scripts 來檢查您的 Linux 系統、相關的套件屬性等等，這個步驟相當的重要， 因為未來您的安裝資訊都是這一步驟內完成的！另外，這個步驟的相關資訊應該要參考一下該目錄下的 README 或 INSTALL 相關的檔案！！基本上，這個步驟完成之後會建立( 或修改 )一個 Makefile ，這就是參數檔啦！


2. make clean
   make 會讀取 Makefile 中關於 clean 的工作。這個步驟不一定會有，但是希望執行一下！ 為什麼呢？因為在進行編譯的時候，會產生一些 *.o 的檔案，例如有個 abc.c 的原始碼，經過編譯後會產生 abc.o 的檔案！我們稱這些檔案為 object file ，這些檔案如果之前已經編譯過並留下來的話，那麼這次再編譯的時候， 就不會編譯該檔案，然而由於我們可能已經修改了部分的參數，因此該檔案的編譯結果事實 上應該會有所不同！因此，為了避免前一次留下來的資料可能影響到這次編譯的結果， 所以通常可以進行一下這個步驟囉！


3. make
   make 會依據 Makefile 當中的預設工作進行編譯的行為！編譯的工作主要是進行 gcc 來將原始碼編譯成為可以被執行的 object files ，但是這些 object files 通常還需要一些函式庫之類的 link 後，才能產生一個完整的執行檔！使用 make 就是要將原始碼編譯成為可以被執行的可執行檔，而這個可執行檔會放置在目前所在的目錄之下， 尚未被安裝到預定安裝的目錄中；


4. make install
   通常這就是最後的安裝步驟了，make 會依據 Makefile 這個檔案裡面關於 install 的項目，將上一個步驟所編譯完成的資料給他安裝到預定的目錄中， 就完成安裝啦！

請注意，上面的步驟是一步一步來進行的，而 其中只要一個步驟無法成功，那麼後續的步驟就完全沒有辦法進行的！ 因此，要確定每一的步驟都是成功的才可以！舉個 例子來說，萬一今天你在 ./configure 就不成功了，那麼就表示 Makefile 無法被建立起來，要知道，後面的步驟都是根據 Makefile 來進行的，既然無法建立 Makefile ，後續的步驟當然無法成功囉！另外，如果在 make 無法成功的話，那就表示原始檔案無法被編譯成可執行檔，那麼 make install 主要是將編譯完成的檔案給他安裝下去的，既然都沒有成功的執行檔了，怎麼進行安裝？ 所以囉，要每一個步驟都正確無誤才能往下繼續做！此外，如果安裝成功， 並且是安裝在獨立的一個目錄中，例如 /usr/local/packages 這個目錄中好了，那麼您就必需手動的將這個套件的 man page 給他放到 /etc/man.config 裡面去。

---

一般 Tarball 套件安裝的建議事項( 如何移除？升級？ )

或許您已經發現了也說不定，那就是為什麼前一個小節裡面， Tarball 要在 /usr/local/src 裡面解壓縮呢？呵呵！基本上，在預設的情況下，原本的 Linux distribution 釋出安裝的套件大多是在 /usr 裡面的，而使用者自行安裝的套件則建議放置在 /usr/local 裡面。這是考量到管理使用者所安裝套件的便利性。

怎麼說呢？我們曉得幾乎每個套件都會提供線上說明的服務，那就是 info 與 man 的功能。在預設的情況下， man 會去搜尋 /usr/local/man 裡面的說明文件， 因此，如果我們將套件安裝在 /usr/local 底下的話，那麼自然安裝完成之後， 該套件的說明文件就可以被找到了。此外，如果您所管理的主機其實是由多人共同管理的， 或者是如同學校裡面，一部主機是由學生管理的，但是學生總會畢業吧？ 所以需要進行交接，如果大家都將套件安裝在 /usr/local 底下，那麼管理上不就顯的特別的容易嗎？！

所以囉，通常我們會建議大家將自己安裝的套件放置在 /usr/local 下，至於原始碼( Tarball )則建議放置在 /usr/local/src( src 為 source 的縮寫 )底下啊。

再來，讓我們先來看一看 Linux distribution 預設的安裝套件的路徑會用到哪些？我們以 apache 這個軟體來說明的話( apache 是 WWW 伺服器軟體，詳細的資料請參考伺服器架設篇。 您的系統不見得有裝這個套件 )：

• /etc/httpd
• /usr/lib
• /usr/bin
• /usr/share/man

我們會發現套件的內容大致上是擺在 etc, lib, bin, man 等目錄當中，分別代表『設定檔、函式庫、執行檔、線上說明檔』。 好了，那麼你是以 tarball 來安裝時呢？如果是放在預設的 /usr/local 裡面，由於 /usr/local 原本就預設這幾個目錄了，所以你的資料就會被放在：

• /usr/local/etc
• /usr/local/bin
• /usr/local/lib
• /usr/local/man

但是如果你每個套件都選擇在這個預設的路徑下安裝的話， 那麼所有的套件的檔案都將放置在這四個目錄當中，因此，如果你都安裝在這個目錄下的話， 那麼未來再想要升級或移除的時候，就會比較難以追查檔案的來源囉！ 而如果您在安裝的時候選擇的是單獨的目錄，例如我將 apache 安裝在 /usr/local/apache 當中，那麼您的檔案目錄就會變成：

• /usr/local/apache/etc
• /usr/local/apache/bin
• /usr/local/apache/lib
• /usr/local/apache/man

呵呵呵呵！單一套件的檔案都在同一個目錄之下，那麼要移除該套件就簡單的多了！ 只要將該目錄移除即可視為該套件已經被移除囉 ！以上面為例，我想要移除 apache 只要下達『rm -rf /usr/local/apache』 就算移除這個套件啦！當然囉，實際安裝的時候還是得視該軟體的 Makefile 裡頭的 install 資訊才能知道到底他的安裝情況為何的。因為例如 sendmail 的安裝就很麻煩......這個方式雖然有利於套件的移除，但不曉得您有沒有發現， 我們在執行某些指令的時候，與該指令是否在 PATH 這個環境變數所記錄的路徑有關，以上面為例，我的 /usr/local/apache/bin 肯定是不在 PATH 裡面的，所以執行 apache 的指令就得要利用絕對路徑了，否則就得將這個 /usr/local/apache/bin 加入 PATH 裡面。另外，那個 /usr/local/apache/man 也需要加入 man page 搜尋的路徑當中啊！

除此之外， Tarball 在升級的時候也是挺困擾的，怎麼說呢？我們還是以 apache 來說明好了。WWW 伺服器為了考慮互動性，所以通常會將 PHP+MySQL+Apache 一起安裝起來( 詳細的資訊請參考伺服器架設篇 )，果真如此的話，那麼每個套件在安裝的時候『 都有一定的順序與程序！』因為他們三者之間具有相關性， 所以安裝時必需要三者同時考慮到他們的函式庫與相關的編譯參數。那麼如果今天我只要升級 PHP 呢？有的時候因為只有涉及動態函式庫的升級，那麼我只要升級 PHP 即可！其他的部分或許影響不大。但是如果今天 PHP 需要重新編譯的模組比較多，那麼可能會連帶的，連 Apache 這個程式也需要重新編譯過才行！真是有點給他頭痛的！沒辦法啦！使用 tarball 確實有他的優點啦，但是在這方面，確實也有他一定的傷腦筋程度。

由於 Tarball 在升級與安裝上面具有這些特色，亦即 Tarball 在反安裝上面具有比較高的難度( 如果您沒有好好規劃的話～ )，所以，為了方便 Tarball 的管理，通常我們會這樣建議使用者：

1. 最好將 tarball 的原始資料解壓縮到 /usr/local/src 當中；


2. 安裝時，最好安裝到 /usr/local 這個預設路徑下；


3. 考慮未來的反安裝步驟，最好可以將每個套件單獨的安裝在 /usr/local 底下：
   例如安裝 rp-pppoe-2.6.tar.gz 時，則可以指定該套件需要安裝於 /usr/local/rp-pppoe 當中，如此一來，該套件會將所有的資料都寫入 /usr/local/rp-pppoe 當中，因此，未來如果要移除該套件，只要將該目錄刪除即可視為成功的移除了！


4. 加上 man path
   不過單獨安裝某個套件在某一特定路徑下的作法，會導致當有 man page 的時候，使用預設的 MANPATH 會找不到相關的說明檔案內容。這個時候就必須要將 man page 的路徑加到 /etc/man.config 檔案中了！否則使用 man 也查詢不到指令的使用方法的。以上面的例子為例，如果是安裝了 /usr/local/rp-pppoe 當中，通常 man page 會放在 /usr/local/rp-pppoe/man 當中，所以，您就必需要在 /etc/man.config 裡面差不多 40~50 行左右的地方，加入底下這一行：
   
   MANPATH /usr/local/rp-pppoe/man
   
   這樣就可以使用 man 來查詢資料囉！