# 6.3\. 包管理 對于 LFS BOOK，包管理通常被請求加進去。一個包管理器允許跟蹤文件的安裝，使刪除或升級軟件包變得簡單。在這一部分里，我們不會討論或者是推薦任何一個包管理器。我們講述的是一些流行的技術，以及他 們是怎么工作的。對于你來說，一個完美的包管理器可能在這些技術之中，也可能是一些技術的結合。這一部分 簡明的描述了當升級軟件包的時候會出現的幾個問題。 LFS 和 BLFS 中沒有涉及包管理器的幾個原因有： * 把精力拿來做包管理器，就偏離了我們的LFS的初衷：一個Linux系統是如何構建的。 * 包管理有很多解決方案，每一個都有優點和缺點。任何一個都不會令其他種類的fans滿意的。 有一些hints是關于包管理。可以查看 [_Hints subproject_](http://www.linuxfromscratch.org/hints/downloads/files/) 來選擇一個適合你的。 ## 6.3.1\. 升級問題 一個包管理器會使升級一個軟件包到新的版本變得很簡單。通常 LFS 和 BLFS 手冊中的說明可以用來升級軟件包。 這里有幾點，你在升級軟件包的時候應該注意的，尤其是在一個運行著的系統上。 * 如果工具鏈中的一個軟件包 (Glibc, GCC 或 Binutils)需要升級到一個新的次版本，重新構建LFS是比較安全的。 盡管你可以按照依賴關系，只是重新構建一部分的軟件包。但我們并不推薦這樣做。例如，如果 glibc-2.2.x 需要 升 級到 glibc-2.3.x,重新構建是比較安全的。對于小版本的升級，簡單的重新安裝通常可以正常的工作，但是不能夠保證。 例如，從 glibc-2.3.4 升級到 glibc-2.3.5 通常不會有問題。 * 如果包含一個共享庫的軟件包升級，并且共享庫的名字發生了變化。動態鏈接到這個庫的所有的 包都需要重新編譯鏈接到新的庫（注意包的版本和庫的名字沒有關系）。例如，一個軟件包 foo-1.2.3 安裝了一個名為 `libfoo.so.1` 的共享庫。你升級這個包到新版本 foo-1.2.4，這個新版本安裝名為 `libfoo.so.2` 的共享庫。這種情況下，所有鏈接到 `libfoo.so.1` 的包都需要重新編譯鏈接到 `libfoo.so.2`。注意在依賴的軟件包沒有編譯完之前，不要刪除原來的庫。 ## 6.3.2\. 包管理技術 下面是一些常用的包管理的技術。在決定安裝包管理器之前，對多種包管理技術進行一下研究，找出某一種的缺點。 #### 6.3.2.1\. 全部記在心里！ 是的，這是一種包管理的技術。一些人不需要包管理器，因為他們對包都非常熟悉，知道每一個包所安裝的文件。 一些人也不需要包管理器，是因為當一個軟件包改變時，他們重新構建整個系統。 #### 6.3.2.2\. 分別安裝到不同目錄 這是一種最簡單的包管理方式，不需要安裝額外的軟件包來管理安裝過程。每一個軟件包安裝到不同的目錄下。 例如，包 foo-1.1 安裝到 `/usr/pkg/foo-1.1` ，創建一個從 `/usr/pkg/foo` 指向 `/usr/pkg/foo-1.1` 的符號鏈接。當安裝一個新版本 foo-1.2 時，它會安裝在 `/usr/pkg/foo-1.2` ，前面的符號鏈接也指向新版本。 一些環境變量，像 `PATH`, `LD_LIBRARY_PATH`, `MANPATH`, `INFOPATH` 和 `CPPFLAGS` 都需要增加 `/usr/pkg/foo`。當軟件包數量大了之后，就難于管理了。 #### 6.3.2.3\. 符號連接風格的包管理 這是前面包管理技術的一個變種。每一個包也是按照類似于前面方法進行安裝。但是不是創建符號鏈接， 而是每一個都被鏈接到 `/usr` 目錄。這樣就不需要添加環境變量了。盡 管有時在安裝的時候符號鏈接自動創建，還是有很多的是采用這種方法的。一些比較流行的有： Stow，Epkg，Graft，和 Depot。 安裝過程需要偽造，這樣包就會認為自己被安裝到了 `/usr` 目錄，盡管實際上 它們安裝到 `/usr/pkg` 目錄下。以這種風格安裝并不是很麻煩的事情。比如，你要 安裝一個包 libfoo-1.1 。用下面的指令安裝就不合適： ``` ./configure --prefix=/usr/pkg/libfoo/1.1 make make install ``` 安裝是沒有問題，但是依賴的包不能夠像你想像的那樣鏈接到 libfoo。如果你編譯一個鏈接到 libfoo 的包， 你就要注意，要鏈接到 `/usr/pkg/libfoo/1.1/lib/libfoo.so.1` ，而不是 像你想像的那樣鏈接到 `/usr/lib/libfoo.so.1`。正確的方法是使用 `DESTDIR` 來偽造包的安裝。可以這樣來使用這種方法： ``` ./configure --prefix=/usr make make DESTDIR=/usr/pkg/libfoo/1.1 install ``` 大多數的包都支持這種方法，但還是有一些不支持。對于這些不兼容的包，你可以手工安裝，或許把一些有問題的包 安裝到 `/opt` 可能更簡單。 #### 6.3.2.4\. 基于時間戳 這種技術里，在安裝包之前，會創建一個時間戳標記文件。安裝之后，簡單的使用的 `find` 命令的某些選項就能生成一個時間戳標記文件創建之后安裝的文件的日志。install-log 就是利用這種技術寫的包管理器。 盡管這種方法簡單，但是它有兩個缺點。如果在安裝的過程中，安裝的文件的時間戳不是當前的時間，這些文件將不會被包管理器記錄。 另外，這種方案只能用在一次只有一個包安裝時。如果有兩個包在兩個終端下同時安裝，那么這時的日志是不可靠的。 #### 6.3.2.5\. 基于LD_PRELOAD 這種方法下，在安裝之前會有一個庫被提前加載。在安裝的過程中，這個庫就會跟蹤正在安裝的包，通過給自己附加上 各種可執行性的動作，像 `cp`, `install`, `mv` 。來跟蹤那些修改文件系統系統調用。為了讓這種方法正 常的工作，所有的可執行文件需要都是動態鏈接的且沒有設置 suid 和 sgid 位。預先加載庫可能會產生一些討厭的 副作用。因此，建議做一些測試，來確保包管理器不會破壞任何東西，并且能夠記錄所有適當的文件。 #### 6.3.2.6\. 創建包的歸檔 在這種方案中，包被分別安裝到不同的目錄樹下，就像符號連接風格的包管理描述的。安裝之后， 系統就會使用安裝的文件創建一個包的歸檔。這個檔案可以在本機上安裝包，甚至可以在其他機器上 安裝包。 這種方法被大多數商業發行版的包管理器采用。例如，RPM（自然是[_Linux Standard Base Specification_](http://lsbbook.gforge.freestandards.org/package.html#RPM)所必需），pkg-utils，Debian 的 apt 和 Gentoo 的 Portage 系統。 有一個描述在 LFS 系統中如何應用這樣的包管理器的hint，參見 [_http://www.linuxfromscratch.org/hints/downloads/files/fakeroot.txt_](http://www.linuxfromscratch.org/hints/downloads/files/fakeroot.txt). #### 6.3.2.7\. 基于用戶的管理 這種方案是 LFS 特有的，是由 Matthias Benkmann 提出的，可以參考 [_Hints Project_](http://www.linuxfromscratch.org/hints/downloads/files/)。在這種方案里，每一個包都是以不同的用戶安裝到標準的目錄里。通過檢驗 user ID 可以很容易的標識一個軟件包。這種方法的特點和缺點非常復雜，這里就不描述了。詳細內容參見 [_http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt_](http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt)。