下面蒐錄了幾個自己學習過程上，或是與人討論時，歸納出的幾個初學者在使用debian package時，常見的幾個迷思。
本篇文章以Ubuntu作業系統為例。
Debian package簡介
Debian package是Debian作業系統發展出來的、模組式地管理作業系統上程式的新增、移除與修改。在Linux的世界中有許多方式去管理系統中的程式，包括tar ball，rpm套件等等，debian package，也常被簡寫為deb，則是眾多管理方式中的其中一種。
Debian package管理模式是一個出色的管理方式。據說在2013年使用人口開始超過使用rpm套件的使用者。這裡有一篇不是很正式的測試指出在2010年對於同一個Linux distribution，下載deb的次數已遠大於其他的、包括tar ball形式的套件形式。請注意這些統計數字不是嚴格考證過的。
下面開始介紹幾個初學者常見的迷思。
套件只是作業系統的一部分
Ubuntu是從Debian改過來的系統，因此也承襲了Debian透過debian package來管理系統中的套件/軟件包/套件包/package的方法。事實上，整個Ubuntu作業系統大體上可以看成是許多的debian package集合而成。
透過適當地新增、刪減套件，可以發行「新的」Ubuntu。升級Ubuntu本質上可以看做是大幅度地更動許多套件的類型與版本。LUbuntu、KUbuntu或是Linux Mint等等Ubuntu延伸版本，可以概括地認為是另外不全然相同的一群debian package集合。
移除.deb可以讓系統回復到原本的狀態
安裝、升級.deb事實上大多數時候，特別是該套件牽扯到眾多的相依函式庫或是設定檔時，是一個不可逆的過程。
舉例來說，若有個.deb其中某個設定檔，是個在系統中會和人共享的設定檔。在移除.deb包的時候，有可能當初打包的debian package maintainer考量到此設定檔有可能要留給另外一個程式使用，因此不會將此設定檔移除或是做修改。
當程式很小或是系統很單純的時候，對於當初打包的人來說，考量到的因此足夠因應所有的情境，這時候的確有可能能夠真正「乾淨地」移除，使得系統回復好像從來沒有安裝過這個.deb包一樣。可惜現實世界中，一個系統通常牽扯到成千上萬個.deb包，或是一個.deb包通常足夠複雜。因此，如果是在進行除錯工作，需要回復到「乾淨的環境」以進行測試的時候，要注意移除.deb包的行為可能不是可逆的，免得想要複製的bug一直無法複製，白白花了時間。
一個程式只能包成一個package
debian package分為source package與binary package，一個source package在編譯之後，可以產生許多個binary package。通常我們拿到的、馬上要提供給自己電腦安裝的是binary package。binary package裡面包的是已經在適當的環境與機器上面編譯好的二進位可執行檔（如果是直譯式語言通常就是程式碼），以及如何佈署的資訊。
許多專案的程式碼在開發的時候，會統一管理所有相關的程式碼。這些程式碼可能各司其職，並在必要的時候又可以互相輔助或是合作。這個統一管理的程式碼通常是被包成一包source package，透過適當的編譯產生好幾個binary package。舉例來說，一個有產生出數個binary package的典型案例可能看起來像是有：
本篇文章以Ubuntu作業系統為例。
Debian package簡介
Debian package是Debian作業系統發展出來的、模組式地管理作業系統上程式的新增、移除與修改。在Linux的世界中有許多方式去管理系統中的程式，包括tar ball，rpm套件等等，debian package，也常被簡寫為deb，則是眾多管理方式中的其中一種。
Debian package管理模式是一個出色的管理方式。據說在2013年使用人口開始超過使用rpm套件的使用者。這裡有一篇不是很正式的測試指出在2010年對於同一個Linux distribution，下載deb的次數已遠大於其他的、包括tar ball形式的套件形式。請注意這些統計數字不是嚴格考證過的。
下面開始介紹幾個初學者常見的迷思。
Ubuntu是從Debian改過來的系統，因此也承襲了Debian透過debian package來管理系統中的套件/軟件包/套件包/package的方法。事實上，整個Ubuntu作業系統大體上可以看成是許多的debian package集合而成。
透過適當地新增、刪減套件，可以發行「新的」Ubuntu。升級Ubuntu本質上可以看做是大幅度地更動許多套件的類型與版本。LUbuntu、KUbuntu或是Linux Mint等等Ubuntu延伸版本，可以概括地認為是另外不全然相同的一群debian package集合。
安裝、升級.deb事實上大多數時候，特別是該套件牽扯到眾多的相依函式庫或是設定檔時，是一個不可逆的過程。
舉例來說，若有個.deb其中某個設定檔，是個在系統中會和人共享的設定檔。在移除.deb包的時候，有可能當初打包的debian package maintainer考量到此設定檔有可能要留給另外一個程式使用，因此不會將此設定檔移除或是做修改。
當程式很小或是系統很單純的時候，對於當初打包的人來說，考量到的因此足夠因應所有的情境，這時候的確有可能能夠真正「乾淨地」移除，使得系統回復好像從來沒有安裝過這個.deb包一樣。可惜現實世界中，一個系統通常牽扯到成千上萬個.deb包，或是一個.deb包通常足夠複雜。因此，如果是在進行除錯工作，需要回復到「乾淨的環境」以進行測試的時候，要注意移除.deb包的行為可能不是可逆的，免得想要複製的bug一直無法複製，白白花了時間。
debian package分為source package與binary package，一個source package在編譯之後，可以產生許多個binary package。通常我們拿到的、馬上要提供給自己電腦安裝的是binary package。binary package裡面包的是已經在適當的環境與機器上面編譯好的二進位可執行檔（如果是直譯式語言通常就是程式碼），以及如何佈署的資訊。
許多專案的程式碼在開發的時候，會統一管理所有相關的程式碼。這些程式碼可能各司其職，並在必要的時候又可以互相輔助或是合作。這個統一管理的程式碼通常是被包成一包source package，透過適當的編譯產生好幾個binary package。舉例來說，一個有產生出數個binary package的典型案例可能看起來像是有：
- 程式核心，可能會有 <套件名稱>-core 這種命名
- 程式外掛，可能會有 <套件名稱>-plugin 這種命名
- 程式對某種語言的函式庫包，可能會有 lib<套件名稱>-<函式庫版號> 這種命名
- 除錯資訊，可能會有 <套件名稱>-dbg 或是 <套件名稱>-dbgsym 這種命名
- 開發工具，可能會有 <套件名稱>-dev 這種命名
釐清這種一對多的概念，除了在看懂Launchpad這個平台的使用架構上，是很有幫助的以外。在自己選擇哪種.deb套件包安裝上，會比較了解某些套件之間可能是有關係的。在這種情形下，再搭配Launchpad或是apt這個工具，相信讀者會更清楚、輕易地知道自己可能需要哪些套件，而不至於胡亂裝了一些自己不需要的東西。
延伸閱讀
fourdollars的投影片
延伸閱讀
fourdollars的投影片
沒有留言:
張貼留言