Linux 的軟件管理及配置 - 安裝、卸載、升級、依賴

1. 對比：Windows 和 Linux 上軟件的安裝與卸載

大部分 Linux 使用者都是從 Windows 轉過來的，先對這倆作個對比，有助理解。

就像在 Windows 下，不少軟件也有安裝版與免安裝版同樣，在 Linux 下也有這樣的差異。

1.1. Linux 的包管理工具（rpm/yum、dpkg/apt）

Windows 下的安裝版軟件在安裝時須要管理員權限，它會在系統的註冊表中添加關於本身的信息，也可能會在系統的某些某些地方添加一些文件。通常而言，這樣的軟件都會在安裝目錄下提供一個名爲uninstall.exe的文件，它會逆向執行安裝操做。（這裏存在的問題是，這個 uninstall.exe 真的能把軟件卸載乾淨麼？因而就產生了各類問題。）
相對的，Linux 的包管理工具，（常見的有apt/dpkg yum/rpm）也須要 root權限，安裝時會將軟件的依賴、安裝位置等信息寫入某個地方，在卸載時會執行安裝的逆向操做，不過通常只卸載軟件自己，而不會卸載依賴。使用 apt 的話，須要用 autoremove 選項，這樣卸載時，也會自動卸載依賴。（從軟件倉庫在線安裝和下載 deb rpm 離線安裝都屬此類）

關於依賴(我的揣測）：Winodws 是低耦合設計，官方運行時庫所有打包成Microsoft Visual C++ 20xx ，其餘依賴一概打包進軟件自己。所以基本沒據說過 依賴管理 這樣的說法。而 Linux 是高耦合度的設計，好處是能夠高度自定義，不須要的東西均可以移除。可是這種環境下，依賴管理就變得很重要。

1.2. 免安裝二進制 tarball

而免安裝軟件呢，Windows 和 Linux 都差很少。只須要將軟件解壓（下載好的軟件應該是 tar.gz 或 zip 格式，須要解壓），就能直接用了。
這種 tarball 通常是靜態連接進了它自己全部的依賴，所以能實現多發行版通用。

免安裝軟件須要用戶本身記住安裝位置，要刪除的時候，直接刪除掉解壓出來的文件夾就好了。（若是使用程序時，它沒執行過其餘操做的話。）

1.3. Linux 和 Windows 用戶的使用習慣

Windows 的用戶羣大，安裝版軟件最流行，這種方式能方便用戶管理本身安裝的軟件。並且 Windows 軟件體系的兼容性作得特別好，十年前在 Xp 上編譯的軟件，極可能仍然能在最新的 Win10 流暢運行。（這也是形勢所迫吧，在 Windows 上，讓普通用戶去從源碼編譯幾乎是不可能的，所以開發者別無選擇，只能發佈 exe 格式。）
而 Linux 系推崇開源，所以通常不會預裝任何非開源的軟件。若是須要這類非開源的軟件，用戶只能自行安裝。並且 Linux 的軟件兼容性遠不如 Windows，不少二進制包，在不一樣發行版、甚至同一發行版的不一樣版本之間，都是不能通用的。

1.4. Linux 系的軟件有以下特點：

1. Linux 系的開源軟件，若是是用戶羣少的或者更新很快的，可能只會發佈源碼tarball，須要自行編譯安裝，不會發布各平臺的編譯版。即便有編譯版，也可能只會提供 deb rpm 這樣用戶羣大的，還可能不會及時更新。（Linux 社區崇尚開源，這和之前的 WIndows 大相徑庭。不過這也使 Linux 的軟件安裝過程受人詬病）
2. 用戶羣大的商業軟件，如 Jetbrains 系，只發布通用的二進制 tar.gz 包，也就是免安裝版，而 Oracle JDK 則只發布 tar.gz 和 rpm.（大概考慮到不少 CentOS 服務器有用 JDK 吧）
3. 用戶羣大的開源軟件，通常會提供 tar.gz 的源碼和 binary.tar.gz.

總結一下就是，Linux 方面，通用的免安裝包好像很流行，而安裝包只能用於特定發行版，不太討喜。另外不少工具做者偏心使用 Python/Nodejs，這類工具不須要編譯，可直接使用 pip/npm 安裝。
使用 Linux 的大部分都是程序員，所以源碼版也很受歡迎。從源碼安裝有更大的自由度，編譯出的程序也能夠特定於本身的電腦，省去不少兼容性的東西。簡單的說就是更快更爽。

那下面就分這三種狀況，分別討論軟件的安裝、卸載、依賴管理等。

2. 免安裝二進制tarball

這種包通常是 tar.gz 或 tar.xz 格式，解壓後，cd 到 bin 目錄，裏面會有一個與軟件同名的腳本或可執行文件，直接運行它就啓動軟件了。並且這種包貌似是能在各發型版上通用的（eg. pycharm nodejs jdk etc.）
通常咱們在 Linux 上安裝了軟件後，都但願可以在 shell 裏直接啓動它。要作到這個，須要先了解 Linux 的 shell 環境變量配置文件

• 全局環境
  • /etc/profile 系統的 shell 環境配置文件（僅每一個用戶登陸時加載一次，不建議修改）
  • /etc/bash.bashrc 系統的 bash shell 環境配置文件（每次開啓一個新 bash，都會加載。若是須要對全部用戶都生效的 bash 環境，就修改這個）
• 用戶環境
  • ~/.profile [也多是 ~/.bash_profile] 用戶我的的 shell 環境配置文件，至關於 /etc/profile 的我的 patch。通常來講它設定一些用戶我的的環境變量，而後執行 ~/.bashrc。
  • ~/.bashrc 用戶我的的 bash shell 配置文件（一樣每次開新 bash 都會加載）
• source ：在當前 shell 中執行指定的 shell 腳本。經常使用於環境設定檔。（這樣作，運行後的變量會存在於當前shell，也就完成了所謂的環境設定。而若是是普通的直接運行的話，會啓用新shell來運行該腳本，運行結束環境就銷燬了。）

由上述配置文件引伸，用戶安裝二進制 tarball 時，一般有兩種作法：

1. 一種就是將該軟體的 bin 目錄添加進PATH中（這會使該 bin 目錄中的全部可執行文件都被加入到 PATH，若是你不想這樣，請考慮第二種方法），也就是將相關命令寫入 shell 配置文件中。至於應該添加到哪裏，看了上面的說明，你應該已經懂了。

   舉例來講，安裝一個軟件時，若是該軟件你們都要用，就應該寫入系統配置裏，而後若是你基本只用 bash，寫 bashrc 裏更方便(修改可當即生效)，不然選profile。
   而若只有你我的須要該軟件，確定要放用戶配置裏，再考慮你是否是用其餘 shell。通常來講放 bashrc 裏總沒問題，而放 profile 裏，有時會須要手動 source /etc/profile 一下才能用。

2. 第二種呢，就是向PATH默認就會包含的那些目錄中（例如 /usr/local/bin），添加啓動腳本。（使用 python 或 shell 編寫）Jetbrains 家的軟件在檢測到該軟件的 bin 目錄未添加進 PATH 時，就會提示你這麼幹。（idea 會向 /usr/local/bin 添加名爲 idea 的 python 啓動腳本）

而若是是安裝 JDK，這以後你還須要手動配置 JAVA_HOME、並將其 bin 目錄加入 PATH.

3.使用安裝包安裝

這種方式就和 Windows 的安裝包相似，可是該安裝包只能用於特定的發行版，由於不一樣的發行版使用不一樣的包機制。最多見的是dpkg 和 rpm，它們也存在對應的在線安裝機制，就是apt 和 yum.
待續

4. 從源碼編譯安裝

從源碼編譯安裝好處已經說了，自由度更高，兼容問題更少，性能更高等。缺點就是編譯比較麻煩，並且安裝好的軟件也很差管理。

gcc 編譯套件（編譯 + 連接）

說到編譯，通常都是 c/c++ 源碼，那在詳細說明以前，這裏有些目錄須要先介紹。

• /lib、/lib64：共享連接庫，包括靜態連接庫 *.a，和動態連接庫 *.so. 使用 gcc 編譯時，默認會從這裏查詢須要的連接庫。不在此列的連接庫須要用 -l單個連接庫 或 -L/連接庫所在文件夾 來指定。
• /usr/include：系統頭文件的保存處，使用 gcc 編譯時，默認會從這裏查詢須要的系統頭文件。不在此列的頭文件目錄須要使用-I/頭文件所在文件夾來指定（是大寫的 i）

make 軟件構建工具

在軟件變得龐大時，若是還手動地一次次調用 gcc，就變得不太現實了。這個時候爲了讓計算機自動化地處理這種項目的編譯構建過程，make 誕生了，它依賴 Makefile。（若是項目變得更龐大，即便是手寫Makefile也變得很困難，這時出現了cmake。cmake是用來自動生成Makefile的，它依賴於 CMakeList.txt）
不過流行的開源軟件，makefile.txt 的生成規則早就已經寫在 configure 裏了，你須要作的只是

./configure  --prefix=/home/myname/apps
make
sudo make install

其中的--prefix指定軟件安裝位置。通常都建議指定，方便管理。（P.S. 被其餘軟件依賴的包，可能使用默認位置更方便，否則你安裝上層軟件時會比較麻煩。）安裝前都建議先configure --help 一下，仔細看看 help，省得出問題。
若是使用的是cmake，那就用cmake .替換掉./configure就行。（有時爲了隔離編譯相關文件和源碼，會先建立一個build文件夾，再在該文件夾內運行cmake ..）

話雖如此，仍是須要先安裝好編譯須要的依賴，才能正常編譯，不然在./configure這一步就會報錯。要從源碼安裝一個軟件，最痛苦的不是在make，而是在處理依賴。要是這依賴的安裝也能自動化就行了。。。

源碼安裝軟件的刪除

從源碼安裝的軟件雖有諸多好處，可是軟件的管理就有點麻煩。首先不少的軟件做者都不會提供相應的make uninstall 命令，所以這麼卸載軟件並不通用。
在使用 make install 安裝好軟件後，必定要記得備份安裝生成的install_manifast.txt，再刪除掉源碼。（這個文件通常會有寫保護）
這以後，若是須要卸載，直接xargs rm < install_manifest.txt 就好了

能夠建立一個備份目錄，專門備份和系統有關的的資料，/etc 和 上述的 install_manifest.txt（建議更名爲「軟件名_install_manifest.txt」）均可以算做此類。

軟件的配置

用 Windows 時咱們都習慣 GUI 配置界面，（配置會自動寫入註冊表）而在 Linux 上，由於 CLI(Command Line Interface) 的流行，配置基本都經過修改配置文件來實現，所以瞭解配置文件的位置就變得很重要。
雖然軟件開發者能夠自由選擇配置文件的位置，不過有約定俗成的規矩：一個軟件的配置文件，通常會有三份。分別在：

- `/etc/appname.conf` or `/etc/appname/appname.conf`  # 系統層配置，軟件的默認配置，更改須要root權限。通常不建議修改
- `~/.config/appname/appname.conf`                       # 如下都是用戶配置，自定義配置。
- `~/.appname/appname.conf`
- `~/.appname_xxx` or `~/.apprc`   # eg. bash vim

分層配置文件，使軟件的配置更靈活。通常須要修改配置的時候，就修改~/.config/appname/appname.conf就好了。

畫外

最近在包管理工具、構建工具上的思考還挺多的。前幾天才學了下 Python 的 pipenv，今天又瞭解了一下 make/cmake，我忽然發現它的依賴處理好像更坑？而還要手動備份 install_manifest.txt......

Arch 的 Pkgbuild 與 AUR 倉庫

前面說到 yum/apt 都智能用於管理 rpm/deb 這樣特殊格式的包，而 免安裝 tarball 和源碼編譯安裝的包都只能本身手動管理（更新、刪除等）。尤爲是源碼編譯，還須要本身先安裝好各類依賴。
若是你有潔癖，編譯完成後你可能會想刪除掉全部編譯時依賴，那你還要手動一個個刪除掉這些編譯時依賴，可要當心別把運行時依賴給刪掉了。。

Arch 就避免了這樣的弊端（也許 gentoo 也是，不過沒玩過），它使用 pkgbuild 來管理其餘來源的安裝包/源碼包，一鍵安裝，自動處理編譯相關的事務。經過一個公共的 AUR 倉庫，全部用戶都能上傳/使用別人寫好的 build 腳本。並且經常使用的腳本更新都很及時，這真的超棒！

參考

• 第二十一章、軟體安裝：原始碼與 Tarball
• 怎麼卸載用 make install 編譯安裝的軟件？
• Understanding Linux configuration files