使用了四年的 Linux，前三年都是在瞎折騰，浪費了不少時間，也得到了不少經驗與教訓。 現在可能是真的老了，已經不願意折騰了，只希望配置好一個系統之後，就一直使用下去。

為什麼要寫/讀這一篇

使用 Linux 尤其是 CentOS 會遇到一些坑，或是一些有潔癖的人不能忍的事情：

官方源中的軟體包版本太老，在功能上無法滿足需求； 多個源的軟體包存在版本衝突； 手動編譯軟體，預設會將不同檔案放置在 /usr/local 下不同的子目錄下，使得軟體的更新和刪除變得麻煩。 等等…

在經歷了幾次重灌 CentOS 之後，特總結出如下幾條軟體安裝的方法與原則，以儘可能保證當前系統的穩定、整潔，儘可能降低系統潔癖引起的重灌衝動。

以下所說，僅限於 CentOS7，對其他發行版，或許有借鑑意義。

官方源

CentOS 自帶的四個官方源中，預設開啟的有 base、updates、extras，這三個源中包含了約 9000 個軟體包，是最穩定、也是最值得信賴的源。

因而若一個軟體包在官方源內，則應通過官方源安裝:

sudo yum install PackageName

第三方源

官方源雖然包含了很多軟體包，但無法滿足日常需求。幸好有第三方源，可以作為官方源的補充。

在使用第三方源的過程中，最怕遇到這兩個問題：

第三方源和官方源中有相同的包，導致官方源的包被第三方源替代； 多個第三方源中存在同一個軟體包，且版本不一致，存在衝突；

這兩個問題經常是致命的，出現各種預料不到的後果，因而選擇第三方源要遵循如下原則：

只選擇可靠的第三方源，要確保第三方源不會替換官方源中的包； 使用盡量少的第三方源，以保證第三方源之間不會衝突；

就 CentOS 而言，根據以上的原則，使用如下第三方源：

大型第三方源，已確認不會替換官方源的包，且相互之間無衝突 EPEL：包含 6500 多個軟體，科研必備 ELRepo：包含幾十個各種硬體的驅動程式 Nux Dextop：多媒體相關的軟體包（與 EPEL 的個別軟體相沖突，可忽略）

有些小型第三方源，僅包含了幾個軟體，確認與官方源和 EPEL 源不會衝突，也可以新增 Google Chrome：包含了 Google Chrome，不會與官方源和 EPEL 源衝突； Adobe：僅包含 flash 外掛，已確認不會衝突； dropbox：僅包含 dropbox 一個軟體，已確認不會衝突；

因而，若一個軟體包位於 EPEL、ELRepo 中，或一些小型的第三方源中，則新增該第三方源，並用 yum 命令安裝:

sudo yum install PackageName

官方 rpm 包

大部分非開源的軟體，在 CentOS 官方源或 EPEL 中是沒有的。有些軟體的官方網站會提供官方 rpm 包。此時可以從官方網站下載與當前系統對應的 rpm 包，直接用如下命令安裝:

sudo rpm -i PackageName.rpm

比如，WPS for Linux 就是其中一個。在安裝的過程中 rpm 命令會自動檢查依賴關係，若該軟體所依賴的包在官方源和 EPEL 源中可以找到，則自動安裝。

直接安裝 rpm 包的做法相當省事，但該軟體不能由 yum 更新，稍稍麻煩一點。有些軟體，比如前面提到的 Google、Dropbox 和 Adobe 其實也可以通過這種方法安裝，在安裝的同時會給系統新增源，對於這類軟體依然可以很方便的更新與刪除。

解壓即用

有些軟體，官方提供了壓縮包，解壓之後即可直接執行其中的二進位制檔案，比如很多 Java 寫的軟體。這類軟體沒有給原始碼，而是給了可以在當前平臺下直接執行的二進位制檔案。大多數非開源的商業軟體都採取這種辦法。

比如 sublime_text、pycharm、mendeley、TauP、sac 等，直接解壓，然後將解壓後的資料夾複製到 /opt 目錄下，然後將該軟體的 bin 目錄加入到 PATH 中即可。 比如 Mathematics、Matlab、intel studio，軟體包中提供安裝指令碼，執行該指令碼即可安裝；

Linux 下的習慣是，商業軟體或第三方軟體都安裝到 /opt 目錄下，這也是大多數商業軟體包的預設安裝路徑，儘量遵循該習慣。

第三方 rpm 包

有些軟體，CentOS 源和 EPEL 源中找不到，官方又沒有提供 rpm 包，但是其他第三方源提供了 rpm 包。分情況討論：

若該第三方源只包含了很少量的包，且確定這些包與官方源以及其他已使用的第三方源不衝突，則可以新增該第三方源。 若該第三方源包含了很多軟體，很可能與官方源或 EPEL 源有衝突，則不新增該源 若該軟體包沒有複雜的依賴關係，則直接安裝該源中的 rpm 包； 若該軟體包依賴於該第三方源中的其他包，則放棄，尋找其他方法；

第三方包管理器

不同的發行版使用不同的軟體包管理器，CentOS 使用 yum，Ubuntu 使用 apt-get。近些年又出現了一些與發行版無關的第三方包管理器，比如 Linuxbrew、Gentoo Prefix、pkgsrc。

Linuxbrew

Linuxbrew 是由 OS X 平臺下非常流行的 Homebrew 移植到 Linux 下的。Linuxbrew 可以作為系統自帶的包管理器的一個補充。其特色在於：

所有軟體都安裝在 ${HOME}/.linuxbrew 目錄下； 軟體的版本相對很新； install、uninstall、info、list、update、upgrade 等功能 若庫中沒有需要的軟體包，可以很簡單地自己建立 formulae

試用了一下，一個比較坑的地方是，linuxbrew 會自己內部解決依賴問題。比如，我試著通過 linuxbrew 安裝 terminator，然後發現 terminator 依賴於Python，儘管系統已經安裝了 python，linuxbrew 還是會安裝一份 python，又由於 python 依賴於更多的東西，導致又安裝了更多軟體包在 home 下。而且，linuxbrew 是從原始碼編譯軟體的，所以相對來說速度較慢。

編譯原始碼

大部分軟體用前面的幾種方法應該都能安裝上了。如果沒安裝上，那就得問問自己，真的需要安裝這個軟體麼。如果不是非常必要的話就不要安裝啦。如果是必須的軟體，那就必須要手動編譯了。

常見的原始碼編譯，一般也就是如下幾步。當然，具體情況具體對待:

tar -xvf xxxx.tgz ./configure --prefix=/opt/xxxx make sudo make install

一般來說，這類軟體的預設安裝目錄都是 /usr/local ，最終檔案會被分別放在 /usr/local 的 bin、lib、share、man 目錄下。

我個人非常不喜歡這種方式，因為作為一個通過原始碼編譯的軟體來說，意味著編譯者 要完全負起管理該軟體的義務，這樣的放置方式會來更新或解除安裝軟體帶來很多麻煩。 所以我總是會在 configure 的時候加上 prefix 手動指定安裝路徑。要解除安裝該軟體就直接刪除 /opt 下對應的目錄，要更新的話，也可以先刪除，再重新編譯一遍。這樣做稍微麻煩的一點是， 需要手動將該軟體的 bin 目錄加入到 PATH 中，還有可能需要修改 LD_LIBRARY_PATH。 但是一般來說，需要編譯原始碼的軟體很少，所以不會造成太大的麻煩。

編譯程式碼

好吧，其實我不知道該怎麼起標題了。。

前一節 “編譯原始碼” 主要針對的是一些大型軟體包，這一節 “編譯程式碼” 指的是對一些 專業性很強的小程式碼包的處理方式。比如有些軟體包編譯之後實際需要的只是一個 二進位制檔案，這個時候就沒有必要安裝到 /opt 了，合適的方式是在自己的 HOME 下 建立 bin 目錄，並將其路徑加入到 .bashrc 中，然後將編譯生成的二進位制檔案複製 到該目錄下即可:

mkdir ${HOME}/bin echo 'export PATH=${HOME}/bin:$PATH'>> ~/.bashrc

比如我的 ${HOME}/bin 目錄下有如下檔案：

distaz ：給出地球上兩點經緯度，計算震中距和方位角 pssac ：在 GMT 中繪製 SAC 檔案 rdseed ：SEED 格式轉 SAC 格式 win2sac_32 、 catwin32 ：Hi-net 網站提供的用於處理 Hi-net 資料的程式 st ：sublime_text 被安裝到 /opt 目錄下，在此建立一個軟連結，方便在命令列呼叫 sublime text wlt.pl ：校內用於登陸網路通的指令碼，在命令列修改網路埠，好 happy fk 、 fk.pl 、 syn 、 trav ：Prof. Lupei Zhu 的用於計算合成地震圖的程式，原始碼有不少，實際需要用的也就這三個可執行檔案和一個 perl 指令碼。 matlab ：指向 matlab 的一個軟連線；

不要隨便什麼二進位制檔案都往 bin 裡放，這裡只應放一些常用的命令或很通用的工具。

自成系統的軟體

有一類軟體，其擁有眾多模組或包，為了管理這眾多的模組，就需要擁有一個自己的模組 / 包管理器。這其中以 TeX、Perl 和 Python 為代表。對於這一類軟體，其眾多的模組是最大的優勢，也是最值得利用的資源，因而我通常會選擇手動安裝它們，原因如下：

系統的源中不可能包含該軟體的所有模組； 系統的源中該軟體的模組的更新要遠遠滯後於最新版本；

當然，即便是使用系統自帶的版本，也依然可以用該軟體自帶的包管理器來安裝模組。但將導致：

部分模組用系統的 yum 管理，部分模組用軟體自帶的包管理器管理； yum 安裝的模組一般版本較老，軟體的包管理器要安裝的大多是最新版本；

這一方面會導致模組管理的混亂，另一方面用軟體自帶的包管理其安裝模組時，可能會依賴於其他模組的最新版本，若該模組是通過系統 yum 安裝的較舊的版本，則可能導致模組的安裝失敗。

因而，對於這類軟體，一般單獨安裝，並用各自的包管理器管理模組：

TeXLive：通過 TeXLive iso 映象檔案安裝，使用其自帶的 tlmgr 管理包 Perl：通過 plenv 安裝最新版本的 Perl，使用 plenv 自帶的 cpanm 安裝模組 Python：通過 pyenv 安裝最新版本的 Python，使用 Python 自帶的 pip 安裝模組

例外

有規則總有例外。

第三方源

mosquito-myrepo 是一個私人維護的源，其中包含了中文輸入法、QQ、飛信、為知筆記、有道詞典、百度雲以及若干音訊、視訊播放器。我對這個源的態度是又愛又恨，其提供了很多中國人需要的軟體，但因為其依賴於除 EPEL 外的其他第三方軟體源，進而可能導致包衝突。所以對該源的使用，要保持謹慎。

總結

簡單總結一下:

為系統新增 EPEL 源、Nux Dextop、ELRepo 源和個別其他小型第三方源 能夠從源中安裝的就從源中安裝 不能從源中安裝的儘量找 rpm 包安裝 找不到 rpm 包的就試試 linuxbrew 能不手動編譯的就不要手動編譯 。

原文：http://www.jb51.net/os/RedHat/529749.html