apt-get簡介
在Ubuntu系統中，經常要用到apt-get install指令來安裝軟件，由於常常需要root權限來操作，所以搭配sudo食用口感更佳，apt-get指令對於安裝、卸載、升級軟件提供一條龍服務，對比於源碼安裝，實在是業界良心。
源碼安裝
源碼安裝的流程一般是三部曲：
./configure
make
make install
-
./configure是為了檢測目標安裝平台的特征，並且檢查依賴的軟件包是否可用或者是否缺少依賴軟件包，configure事實上是個腳本，最終的目的是生成Makefile。
-
如果第一條指令沒有報錯，會生成一個Makefile，make指令就是編譯這個源碼包
-
正常編譯完之后如果沒有報錯，就生成了可執行文件，make install指令就是將可執行文件放到指定目錄並配置環境變量，允許我們在任何目錄下使用這個軟件。
源碼安裝的優點
對於普通用戶而言，實在是想不到什么優點...
對於軟件開發者而言，可以拿到源碼閱讀學習並修改，geek一個軟件簡直比找女朋友還好玩！同時也可以在一定程度上防止黑客的攻擊(你知道這個版本的漏洞，但是老夫已經把它修復了！！！)
源碼安裝的缺點
其實三部曲的安裝還是不那么麻煩的，前提是不報錯！一旦報錯，對於linux初學者而言，那也真是丈二摸不着頭腦，然后各種百度各種google，按照各種江湖術士的方法來整，結果把系統整崩的情況數不勝數，即使當時能用，但是也有可能留下在以后的使用中經常出現莫名其妙問題的隱患，讓我們來看看這些問題都是啥樣的：
-
./configure報錯： 如果檢查到缺少依賴或者依賴文件的版本不匹配呢？一般出現這種情況，就自己解決吧，一般的做法是，升級軟件包或者安裝缺少的依賴軟件包，運氣好的話，解決報錯的依賴問題就行了，運氣不好的話，A軟件包依賴B，B又依賴C.....這是比較常見的linux勸退方式，從入門到放棄！
-
make報錯，由於源碼包的形式多是個人用戶更新維護的，所以可能出現一些平台沒測試到位或者在特定平台上程序出現bug的情況，這種情況就沒辦法了，如果你有能力debug那當然另說
-
make install 報錯，這個指令報錯的形式一般僅僅是沒有權限，加上sudo就行。但是同時因為源碼包多由個人維護，也經常可能出現造成系統垃圾的情況，又或者你需要卸載的時候 make uninstall指令僅僅卸載可執行文件，其他配置文件和依賴文件不作處理。
apt-get指令管理安裝包
在上面說了那么多源碼安裝的缺點，聰明的盆友就要猜我我將要引出今天的主角：apt-get包管理應用軟件，由apt-get管理的軟件包可以輕松做到一鍵安裝卸載。廢話不多說，我們先看看它的常用用法：
sudo apt-get install XXX
sudo apt-get install -y XXX
sudo apt-get install -q XXX
sudo apt-get remove XXX
sudo apt-get purge XXX
sudo apt-get autoremove
sudo apt-get update
sudo apt-get upgrade
apt-get install
一鍵安裝軟件包，與源碼安裝不同的是，這個指令會自動檢測並安裝依賴，而且用apt-get安裝的包都是成熟的軟件包，基本不存在安裝包有嚴重bug或者文件缺失的情況。
sudo apt-get install -y
這里主要將的就是-y選項，添加這個選項就相當於不需要重復地確認安裝
sudo apt-get install -q
即-quiet，靜默安裝，當然也不是完全靜默，會將低等級的log信息屏蔽。
sudo apt-get remove
既然有安裝就會有卸載，remove指令就是卸載，值得注意的是，remove僅僅卸載軟件，但是並不卸載配置文件
sudo apt-get purge
卸載指令，同時卸載相應的配置文件
sudo apt-get autoremove
關於這條指令，官方解釋是這樣的：
autoremove is used to remove packages that were automatically installed to satisfy dependencies for other packages and are now no longer needed
在卸載軟件的時候同時卸載那些當初作為依賴但是現在並不需要的包。
看起來非常完美的指令，但是博主建議慎用！！這條指令很可能將你要用的依賴包同時卸載，有時候你的安裝包並沒有通過apt-get指令來管理，apt-get管理工具不會加入這些包的信息，所以在檢索包的依賴關系時可能出問題.
又或者是另一種情況：舉個例子：在安裝某個包時，這個包依賴git，但是git並非你主動下載的，而是作為依賴下載的，包安裝完之后系統可能就會提示git作為依賴不再需要使用，它並不知道你是不是正在使用這個軟件包。
apt-get update
將所有包的來源更新，也就是提取最新的包信息，這一條我們經常使用到。
apt-get upgrade
這條指令一般執行在apt-get update之后，它的作用是將系統中舊版本的包升級成最新的，慎用！
因為在linux下，由於大部分為非商業軟件，所以穩定性並沒有得到很好的驗證，升級到最新版本需要十分慎重！
apt-get執行原理
如果僅僅知道怎么用而不知道為什么這么用，那就違背了學習使用linux的初衷，所以我們還是需要從原理出發來看apt-get指令時怎么運行的。
提出問題
首先需要知道的問題是：
-
我們用apt-get下載的軟件包是從哪里來的？
-
下載之前要做哪些准備工作？
軟件從哪里來？
所有的deb包由官方統一管理，那為什么我們能定位到這些軟件包呢？這里就涉及到一個軟件源的概念，在/etc/apt/目錄下有一個sources.list文件，我們來看一下這個文件的內容：
cat /etc/apt/sources.list
deb http://security.ubuntu.com/ubuntu trusty-security main restricted
deb-src http://security.ubuntu.com/ubuntu trusty-security main restricted
deb http://security.ubuntu.com/ubuntu trusty-security universe
deb-src http://security.ubuntu.com/ubuntu trusty-security universe
deb http://security.ubuntu.com/ubuntu trusty-security multiverse
deb-src http://security.ubuntu.com/ubuntu trusty-security multiverse
deb http://extras.ubuntu.com/ubuntu trusty main
deb-src http://extras.ubuntu.com/ubuntu trusty main
deb http://us.archive.ubuntu.com/ubuntu/ trusty-proposed main restricted multiverse universe
由於條目太多，這里只貼出一部分。可以看出來的是，這里都是一些資源網站，軟件包資源當然就是出自這里。
下載之前要做哪些工作
實踐出真知，我們來下載一個軟件看看：
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
account-plugin-windows-live libblas3 libbonobo2-0 libbonobo2-common
libbonoboui2-common libglade2-0 libgnomecanvas2-0 libgnomecanvas2-common
libgnomeui-common libidl-common libidl0 libisl10 liblinear-tools liblinear1
libllvm3.5 libntdb1 liborbit-2-0 liborbit2 libupstart1
linux-headers-3.16.0-30 linux-headers-3.16.0-30-generic
linux-image-3.16.0-30-generic linux-image-extra-3.16.0-30-generic
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
libdiodon0 libunique-3.0-0
Suggested packages:
diodon-plugins
The following NEW packages will be installed:
diodon libdiodon0 libunique-3.0-0
0 upgraded, 3 newly installed, 0 to remove and 221 not upgraded.
Need to get 272 kB of archives.
After this operation, 1,348 kB of additional disk space will be used.
Do you want to continue? [Y/n]
這是前期准備工作的log信息，我們可以看到
第一步是Reading package lists，這就是從/etc/apt/sources.list中檢索可用的源中是否有這個軟件包。
然后從下面的log可以看出，下面的步驟就是生成軟件依賴樹，將需要的依賴包提前列出來，在安裝所需軟件之前進行安裝。
經常我們在下載軟件的時候需要先添加源，很多盆友都不知道這是在干什么，看到這里大家應該是能看出個原因了：
因為你需要下載的軟件並不在官方源網站中，所以需要先行添加資源網站，apt-get才能根據相應的源檢索到相應的資源，添加源有很多操作方式，歸根結底就是一個操作結果：在/etc/apt/sources.list添加相應的資源網站，知道了這個，就可以直接在文件中添加源，但是要記住linux下最基本的一個習慣：操作系統文件時先備份。
使用apt-get可能遇到的問題
在使用apt-get install的時候，我們可能會遇到下面的問題：
E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?
碰到這種問題怎么解決呢？
解決方法
這種問題的原因是apt-get被占用，無法再次使用apt-get命令操作。解決辦法分為兩種：
1、在終端輸入，ps -ef | grep "apt-get",這個指令找出占用apt-get應用的進程，然后用sudo kill -9 PID強制結束進程
2、但是也有可能找不到這個占用的進程，很可能你在上一次安裝操作的時候意外斷電，沒有正常退出導致的，這個時候需要做的操作就是強制刪除以下文件就可以：
sudo rm /var/cache/apt/archives/lock
sudo rm /var/lib/dpkg/lock
從這里可以看出，其實就是刪除兩個鎖文件，我們大可以猜想一下，系統在執行apt-get指令安裝時，會在/var/lib/dpkg/和/var/cache/apt/archives/下生成lock文件，當指令正常退出時，系統會刪除這個lock文件。
這樣就可以解釋為什么刪除這兩個文件就可以恢復apt-get的自由。
那我們就來驗證一下，以安裝diodon為例：
sudo apt-get install diodon
在系統詢問是否繼續時，我們先不操作，打開另一個終端。鍵入：
ls /var/lib/dpkg/lock
結果顯示
/var/lib/dpkg/lock
表示是有這個文件的，然后我們關掉apt-get執行的進程，再檢查沒有操作apt-get文件時是否有這個文件：
ls /var/lib/dpkg/lock
結果顯示
/var/lib/dpkg/lock
居然還能查到這個文件，證明我們的猜想是錯誤的！那就再猜測：既然是lock文件，那么就涉及到文件鎖，文件是一直存在的，但是在執行apt-get時被鎖住了，在正常退出的時候被解鎖，立馬行動，同樣的，先鍵入：
sudo apt-get install diodon
並讓其停在用戶確認界面，在查看系統中被鎖住的文件，在終端鍵入：
cat /proc/locks #查看系統中被鎖定的文件
結果顯示：
1: POSIX ADVISORY WRITE 13604 08:01:792131 0 EOF
2: POSIX ADVISORY WRITE 13604 08:01:792927 0 EOF
3: OFDLCK ADVISORY WRITE -1 08:01:393386 0 0
4: POSIX ADVISORY READ 2957 08:01:393504 128 128
5: POSIX ADVISORY READ 2957 08:01:393381 1073741826 1073742335
6: POSIX ADVISORY READ 2926 08:01:393504 128 128
7: POSIX ADVISORY READ 2926 08:01:393381 1073741826 1073742335
8: POSIX ADVISORY READ 2949 08:01:393504 128 128
9: POSIX ADVISORY READ 2949 08:01:393381 1073741826 1073742335
10: POSIX ADVISORY WRITE 2836 08:01:524297 0 EOF
...僅顯示用戶級別
然后關掉apt-get的進程，再次鍵入：
cat /proc/locks #查看系統中被鎖定的文件
結果顯示
1: OFDLCK ADVISORY WRITE -1 08:01:393386 0 0
2: POSIX ADVISORY READ 2957 08:01:393504 128 128
3: POSIX ADVISORY READ 2957 08:01:393381 1073741826 1073742335
4: POSIX ADVISORY READ 2926 08:01:393504 128 128
5: POSIX ADVISORY READ 2926 08:01:393381 1073741826 1073742335
6: POSIX ADVISORY READ 2949 08:01:393504 128 128
7: POSIX ADVISORY READ 2949 08:01:393381 1073741826 1073742335
8: POSIX ADVISORY WRITE 2836 08:01:524297 0 EOF
...#僅顯示用戶級別
對比發現很明顯，在使用apt-get的時候，系統中被鎖定的文件明顯多出兩個，但是那一行數字是什么意思呢？下列是對照關系，
number, type, mode, type, pid, maj:min:inode start end
1： POSIX ADVISORY WRITE 13604 08:01:792131 0 EOF
我們可以通過inode的對比來確認在apt-get操作時多出來的兩個被鎖住的文件到底是不是上述提到的那兩個鎖文件。
ls -i /var/lib/dpkg/lock /var/cache/apt/archives/lock
輸出結果：
792131 /var/cache/apt/archives/lock 792927 /var/lib/dpkg/lock
很顯然，inode為792131,792927的兩個文件恰好是上述進行apt-get操作和不操作時被加鎖的兩個文件，這個猜想是正確的。
但是問題又來了：當apt-get無法獲取這兩個鎖文件的操作權限時，為什么刪除這兩個文件就可以了呢？這不會導致系統問題嗎？
帶着這個疑問，我們繼續來操作：
sudo rm /var/cache/apt/archives/lock /var/lib/dpkg/lock
然后再查詢文件：
ls /var/cache/apt/archives/lock /var/lib/dpkg/lock
輸出結果：
ls: cannot access '/var/cache/apt/archives/lock': No such file or directory
ls: cannot access '/var/lib/dpkg/lock': No such file or directory
這下這兩個文件是刪除干凈了，那我們得趕緊看看apt-get命令是否還能操作：
sudo apt-get install diodon
結果發現還是可以操作，這時候我再來看這兩個文件：
ls /var/cache/apt/archives/lock /var/lib/dpkg/lock
輸出結果：
/var/cache/apt/archives/lock /var/lib/dpkg/lock
居然又有了，這下是明白了，原來當我們遇到apt-get的無法獲取鎖的問題，直接刪除這兩個文件的同時這兩個文件的鎖自然也不存在了，在下一次重新使用apt-get指令時，系統檢測到沒有鎖文件時就會創建這兩個文件，同時進行apt-get操作。
其實這是一種覆蓋式的偷懶操作，我們大可以用修改文件的鎖屬性的方式來解決這個問題，在文件inode結構體中有一個
struct file_lock *i_flock;
直接操作這個結構體就可以，但是這需要涉及到C和linux系統編程方面，在這里就不贅述了。
好了，關於ubuntu中apt-get包管理軟件的討論就到此為止啦，如果朋友們對於這個有什么疑問或者發現有文章中有什么錯誤，歡迎留言
原創博客，轉載請注明出處！
祝各位早日實現項目叢中過，bug不沾身.