這篇文章的圖片鏈接發生了問題，無法正常查看圖片，所以我在CSDN轉載一下，特此聲明。
apt-getremove的行爲我們很好理解，就是刪除某個包的同時，刪除依賴於它的包，例如：A依賴於B, B依賴於C，apt-getremove刪除B的同時，將刪除A(很好理解，A依賴於B，B被刪了，A也就無法正常運行了)
先說明下apt-getautoremove與aptituderemove是一樣的效果的,我們先了解下這兩者的瓜葛
|
1 |
apt-get一開始並沒有記錄auto-install的信息 |
|
|
|
2 |
在apt(0.6.44.2exp1)此版本時(06年)，apt-get增加了類似於aptitude的auto-install記錄(/var/lib/apt/extended_states). |
||
|
3 |
此後，aptitude在版本0.4.5.1(07年)轉向使用apt-get的auto-install記錄，而拋棄了自己原先的記錄方式 |
||
|
4 |
再隨後apt-get在版本0.7.7(07年)增加了autoremove的選項 |
|
|
依賴關係是一個複雜而交錯的鏈條，我們把舉幾個例子來看看它們的行爲
|
1 |
以下圖中，綠色圓是爲了滿足依賴關係而apt-get或aptitude自動安裝上的包 |
||
|
2 |
藍色圓是管理員使用apt-getinstall或aptitudeinstall |
|
|
|
3 |
指定安裝的包，簡稱爲手動安裝的包 |
|
|
例子1:
1.C依賴於或推薦B軟件包(apt-get和aptitude在安裝軟件時除了安裝必要的依賴包，默認也會安裝Recommends關係的包)
2.B 依賴於或推薦A,A被其他手動安裝的包依賴
|
1 |
apt-getremove C將刪除C,同時提示你用apt-getautoremove去清除B |
||
|
2 |
apt-getautoremove C將刪除B,C |
|
|
|
3 |
aptituderemove C將刪除B,C |
|
|
我的理解:刪除C,那麼B這個包既是自動安裝的,且沒有其他手動安裝的包依賴於它,
則可以判定B也是沒必要的
例子2:
1.在例子1的基礎上,D依賴於或者推薦B,且D沒有被其他手動安裝的包依賴
這樣的情況一般出現在用apt-getremove某個手動安裝的包之後.
|
1 |
apt-getremove C將刪除C,同時提示你用apt-getautoremove去清除B,D |
||
|
2 |
apt-getautoremove C將刪除B,C, D |
|
|
|
3 |
aptituderemove C將刪除B,C, D |
|
|
我的理解:刪除C,那麼B,D這兩個包既是自動安裝的,且沒有其他手動安裝的包依賴於它們,
則可以判定B,D也是沒必要的
例子3:
1.在例子2的基礎上,有個手動安裝的包E推薦D(既ERecommends
D,手動安裝E時,也會把D裝上)
|
1 |
apt-getremove C將刪除C,同時提示你用apt-getautoremove去清除B,D |
||
|
2 |
apt-getautoremove C將刪除B,C, D |
|
|
|
3 |
aptituderemove C將刪除B,C, D |
|
|
我的理解:刪除C,那麼B,D這兩個包既是自動安裝的,且沒有其他手動安裝的包依賴於它們,
則可以判定B,D也是沒必要的
雖然D被ERecommend,但爲啥是這麼設計的,我也沒猜出開發人員的想法
例子4:
1.在例子3的基礎上,D變成依賴於B,E變成依賴於D
|
1 |
apt-getremove C將刪除C |
|
|
|
2 |
apt-getautoremove C將刪除C |
||
|
3 |
aptituderemove C將刪除C |
|
|
我的理解:只刪除C,因爲B被D依賴,D被E依賴,間接來說,E不能沒有B,D而正常運行,所以B,D被保留
例子5:
1.在例子4的基礎上,D變成推薦B,E依然依賴於D
|
1 |
apt-getremove C將刪除C,同時提示你用apt-getautoremove去清除B |
||
|
2 |
apt-getautoremove C將刪除B,C |
|
|
|
3 |
aptituderemove C將刪除B,C |
|
|
我的理解:刪除C,而B沒有被其他手動安裝的包直接依賴或者間接依賴(我指那些一層層dependon的關係),D被E依賴
所以B不是必要的,可以刪除,而D不能刪除
