[分享] LFS套件管理法 (翻譯自LFS 6.4章節6.3)
翻譯自：
http://www.linuxfromscratch.org/lfs/view/stable/chapter06/pkgmgt.html
翻譯者：icycandle@gmail.com
只是LFS的一個小章節，但是依然有被獨立閱讀的價值。
心血來潮隨意翻，有不周處歡迎指正，轉錄或再利用請自便。
-------------------------------本文-------------------------------
6.3. 套件管理(Package Management)
套件管理以往被視為LFS的額外部份。一個套件管理者允許追蹤檔
案安裝，使移除與升級套件變得更容易。就像binary與library files，套
件管理者會處理檔案的配置與安裝。在妳開始疑惑之前，不——這一節將不
會談論也不會推薦任何一個套件管理程式。它所提供的是一些較流行技術與
它們運作方式的摘要。屬於妳的完美套件管理程式並不一定就是這些技術，
但也有可能是由它們其中兩者或者三者以上結綜合而來。這個章節僅僅提及
升級套件時可能會發生的某些議題。
一些為何LFS或BLFS中不包含套件管理者的理由如下：
*處理套件管理問題會使得焦點遠離這兩本書的目標——教導一個Linux
系統如何被建立。
*套件管理有太多解決方案，且都各有優劣。要同時滿足所有讀者太困難了。
有某些提示寫在 package management 的主題中。參訪 Hints Project
並去看看是否其中就有你所需要的。
6.3.1. 升級議題(Upgrade Issues)
一個套件管理者使得升級變得更容易。一般來說 LFS 跟 BLFS 中的
instructions 都可以被升級到更新的版本。在升級過程中(特別是在一個運
行中的系統)，這裡有幾點你必須要當心的。
*如果工具鍊中(Glibc, GCC or Binutils)有某個部份需要升級到比較新的
次版本，重建LFS會比較安全。即使你可能透過在滿足相依性下重建所有
軟件包來混過去，我們還是不建議那麼做。舉個例子，如果 glibc-2.2.x
需要被升級到 glibc-2.3.x，那重建LFS會比較安全。如果是微版本的升級
，通常單純的重安裝就可以了，但還是沒有保障。舉例來說，glibc-2.3.4
升級到 glibc-2.3.5 通常就不會造成任何問題。
*如果一個包含公用庫(library)的套件升級了，或是該公用庫的名字改變了
，那麼所有動態連結到該庫的套件都需要被重新編譯以連結到新的庫(library)
。(注意在套件版本與庫名間沒有相關性。)舉裡來說， consider 一個套
件 foo-1.2.3 安裝了一個叫做 libfoo.so.1 的公用庫。假設你升級了這
個套件到新版本 foo-1.2.4 ，而這新版本安裝的公用庫叫做 libfoo.so.2
。在這樣的情形下，所有動態連結到 libfoo.so.1 的套件都需要被重新編
譯以連結到 libfoo.so.2。注意，直到所有依賴的套件被重新編譯，你都
不應該移除舊版本的庫 (library)。
6.3.2. 套件管理技術(Package Management Techniques)
以下是一些常見的套件管理法。在對一個套件管理程式展開討論之前
，對不同的方案做一些研究，特別是對某些方案的缺點部份.
6.3.2.1. 那都在我的腦袋裡！(It is All in My Head!)
是的，這是個套件管理方案。有些人沒有找尋套件管理者的需要，因
為他們密切地理解套件們且知道任何一個已安裝檔案(file)的來源套件。有些
使用者並不需要任何套件管理，是因為升級後他們就會重新安裝整個系統。
6.3.2.2. 單目錄安裝(Install in Separate Directories)
這是一個單純過頭的套件管理方案，不需要任何額外的套件來處理安
裝問題。每個套件都被安裝在同一目錄中。舉例來說，套件 foo-1.1 安裝在
/usr/pkg/foo-1.1，然後製造一個符號連結(symlink) 從 /usr/pkg/foo 連到
/usr/pkg/foo-1.1。當安裝新版本 foo-1.2，它就會安裝在 /usr/pkg/foo-1.2
，然後舊的符號連結(symlink)就會用連到新版本的符號連結置換。
環境變數像是 PATH、 LD_LIBRARY_PATH、 MANPATH、 INFOPATH 與
CPPFLAGS 都需要擴展(expanded)以包含 /usr/pkg/foo。如果套件稍微多一點
的話，這個方案就變得無法管理了。
6.3.2.3. 符號連結流套件管理(Symlink Style Package Management)
這是上一個套件管理方案的變形。套件的安裝方式差不多。但製造動
態連結的部份改為將每個檔案都符號連結至 /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. 時間標記法(Timestamp Based)
在這個方案中，在套件安裝之前檔案是 timestamped。在安裝之後，只
要簡單的使用find指令加上適當的選項便可以在 timestamp 檔案被創造之
後生成所有被安裝檔案的紀錄(log)。install-log 是其中一個用這方式的檔案
管理器。
但即使這個方法有單純化方面的優勢，它還是有兩個缺點。假設，在安
裝過程中， 與timestamp安裝的檔案不是在正確時間下安裝的話，那些檔案就無
法被檔案管理者追蹤。同樣地，這個方法一次只能安裝一個檔案。如果兩個檔案
同時間在不同的終端安裝的話，紀錄(log)就不可靠了。
6.3.2.5. 追蹤安裝腳本(Tracing Installation Scripts)
在這個方案中，安裝腳本執行的指令會被紀錄，這裡有兩個技術可供選
擇:
The LD_PRELOAD 環境變數可以被設定指向一個安裝前預先載入的庫。
在安裝過程中，這個庫會追蹤那些藉由將自身配屬至不同執行檔如cp、install
、mv 來安裝的套件，且追蹤系統對檔案系統修改的呼叫。以這個步驟執行，所
有的可執行檔就不能使用suid或sgid來動態連結。預先載入函式庫可能在安裝過
程中造成某些枝節。因此，建議執行某些測試來保證套件管理者不會破壞任何東
西與紀錄所有適當的檔案。
第二個方法是使用 strace，紀錄安裝腳本執行中的所有系統呼叫。
6.3.2.6. 創造套件資料室(Creating Package Archives)
在這個方案中，套件安裝被假造進入單一的目錄樹，就像符號連結流方
案中所描述的那樣。安裝之後，會使用已安裝的檔案創造一個套件資料出來。這
個資料是用來安裝套件在本地機器上或甚至可以用來安裝套件在其它機器上。
這個步驟被多數商業套件中的檔案管理程式使用，像是RPM (順帶一提
，被Linux Standard Base Specification依賴)，pkg-utils，Debian的apt，與
Gentoo的Portage系統。一個描述如何在LFS系統中採用此種風格套件管理者建議
位於 http://www.linuxfromscratch.org/hints/downloads/files/fakeroot.txt。
6.3.2.7. 使用者標記法(User Based Management)
這個方案，專屬LFS，是 Matthias Benkmann所建議，並於Hints Project
中實用化。在這個方案中，每個套件由不同的使用者安裝至標準地點。套件中附
屬的檔案可以簡單的經由確認使用者 ID 被辨識。這個步驟的特色與缺點太複雜
以至於無法在這裡說明。更多細節請看
www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt
( http://0rz.tw/2lRI0 )。
--
18144 + 4 2/17 thund □ [無言] 好強的球技!!
18145 50 2/17 gibletnoodle □ [腦殘]-第一次下廚(?)
18146 7 2/17 sharon510 □ 寵物奄奄一息，體力用盡。
Ptt版「羅氏墨漬測驗」（Rorschach inkblot test），你會看到什麼？
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.122.205.76
→
02/21 13:32, , 1F
02/21 13:32, 1F
推
02/22 00:54, , 2F
02/22 00:54, 2F
→
02/22 03:23, , 3F
02/22 03:23, 3F