前言
希望提供一篇比較完整的教學，讓想學習如何打包 DEB 套件的人可以參考。
- 以下的流程，除了特別說明之外，大致上 Debian 和 Ubuntu 系統都適用。
- 如果您是拿已經有人打包過的套件來加以修改，請從「 debian/目錄中必備檔案」一節開始閱讀。
Debian 自由軟體方針
老字號的 Debian 有它對套件性質的堅持。為了保持 Debian 百分百自由的純度，官方有份過濾哪些軟體可以成為座上賓的文件，也就是 Debian 自由軟體方針 (The Debian Free Software Guidelines -- DFSG)。
不一定人人都想成為 Debian 的正式維護者，您大可不必遵守這個方針。只是，它裏面列的條文也包含了自由軟體呼籲的東西，如：允許自由重新散佈、衍生軟體等。為了避免日後版權的爭議，同時也為了宣導自由軟體精神，這裡高度建議先看看方針，再來決定您要打包什麼：)
事前準備
在開始您的熱血打包生涯前，請先確認一下打包用的套件是否安裝、設定和一些注意事項：)
可能用到的套件有：
dpkg-dev 解開、製作、上傳 DEB 套件等。
file 這主要是看檔案的類型，如：文字檔、二元檔等。
gcc
g++ 如果是 C++ 寫成的程式，要靠這個來編譯。
libc6-dev 給 gcc 用的C函式庫和標頭檔。
make
patch
perl 有些 script 會用到。
autoconf
automake
dh-make 我們需要它來作“Debian化”，產生相關範本。
debhelper 讓打包變得比較輕鬆的工具。
devscripts 一些好用的 script。
fakeroot 高度建議安裝，讓一般使用者可以不必取得 root 權限就打包。
gnupg 下個章節將會詳細介紹。
lintian 在您打包好之後，用來作後續檢查的程式。
linda 另一個套件檢查程式。
pbuilder 建立 chroot 環境。可以檢查套件所指定的相依性是否正確。
此外，若要打包的程式是用別種程式語言寫的，也要安裝該程式語言所需的套件。
至於設定的部份，因為打包時會要求一些維護者的資訊，預先設定好會讓過程更簡單。
export DEBFULLNAME="Demo User" 這裡請輸入維護者姓名，最好跟稍後 GnuPG 設定的一致。
export DEBEMAIL="demo@demo.org" 維護者的 Email 位址。
您也可以寫在 ~/.bashrc 中，不必每次都重新輸入一遍。
最後是幾個注意事項：
- 先檢查您要包的套件是否已在 Debian/Ubuntu 發行版中，或是已經有另一個人在維護了，以避免傻傻地作白工。
- 涉及安全性的問題要特別注意，如：軟體是否要求 root 權限，來從事跟網路有關或可能對系統安全造成威脅的事。
- 向原軟體的開發群洽詢是否願意授權打包。
- 最重要的是，您已經試用好一段時間，而且該軟體可以正常工作。包一個太多臭蟲的套件，不僅挑戰您的功力，也挑戰使用者的耐心。
準備您的 GnuPG 金鑰
套件驗證是相當重要的一環。為了讓使用者確認套件未被竄改或損毀，DEB 套件的相關檔案使用了 GnuPG 加密和 MD5 加總檢查。因此，我們必須先準備好自己的 GnuPG 金鑰，以便在打包過程中使用。
GnuPG
的工作原理，簡單地來說，每次產生出來的一組金鑰中，包含公眾金鑰和私密金鑰。我們打包出來的檔案，是用私密金鑰加密。上傳到 apt
伺服器後，當使用者下載檔案時，可以用您的公眾金鑰解密。若不是您本人私密金鑰加密的話，是無法用您公眾金鑰解開的。這樣一來，就可以確保檔案是您釋出。
sudo apt-get install gnupg
- 產生 GnuPG 金鑰 (請以一般使用者的權限進行)
gpg --gen-key
gpg (GnuPG) 1.2.5; Copyright (C) 2004 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
Please select what kind of key you want:
(1) DSA and ElGamal (default)
(2) DSA (sign only)
(4) RSA (sign only)
Your selection? 1
DSA keypair will have 1024 bits.
About to generate a new ELG-E keypair.
minimum keysize is 768 bits
default keysize is 1024 bits
highest suggested keysize is 2048 bits
What keysize do you want? (1024) 2048
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 5y
(五年的使用期限是參考官方手冊的示範，您可以依照自己需求指定。)
Key expires at 西元2010年07月09日 (週五) 02時55分23秒
Is this correct (y/n)? y
(這裡建議您 User-ID 跟維護者資訊一致 -- 兩者都是 Name <Email> 的格式，
以便 debhelper 可以正確抓到金鑰)
You need a User-ID to identify your key; the software constructs the user id
from Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"
Real name: Demo User
Email address: demo@demo.org
Comment:
You selected this USER-ID:
"Demo User <demo@demo.org>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
(這裡設定私密金鑰的密碼，請輸入足夠長且不易被猜到的字串。
輸入時並不會顯示任何字元，包括 * 號。重點是要牢記喔，等下打包時會用到：)
You need a Passphrase to protect your secret key.
Enter passphrase:
Repeat passphrase:
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
++++++++ ...
(當加號出現時，請在鍵盤輸入任意字串、移動滑鼠、或搬動硬碟資料。
以便程式可以取得足夠的亂數資訊，提高金鑰的安全性)
之後會列出已經建立好的金鑰。
pub xxxxx/yyyyyyyy 2005-07-09 Demo User <demo@demo.org>
sub zzzzz/wwwwwwww 2005-07-09 [expires: 2010-07-08]
當下次要使用這組金鑰的時候，它的 ID 就是 yyyyyyyy 這組字串。
官方使用手冊建議您立即建立註銷憑證。在私密金鑰洩漏時可以用這個檔案來通知他人，以防有心人士用您的金鑰作壞事。請妥善保存該憑證。
gpg --output revoke.asc --gen-revoke (您的金鑰 ID)
可以下列方式進行
gpg --output demo.gpg --export (您的金鑰 ID) 這是二元檔格式
或 gpg --armor --export (您的金鑰 ID) 這會輸出文字格式
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.2.5 (GNU/Linux)
...
-----END PGP PUBLIC KEY BLOCK-----
把這段文字複製起來，就可以用純文字檔釋出了
其實，官方對金鑰還有嚴謹的規定，如：必須有官方開發人員的背書等。不過這裡並不打算詳述，有興趣的人可以參考官方文件。
套件名稱和版本
相中您想打包的軟體之後，就大大方方地把源碼抓回來囉：)另外，如果您有意成為該軟體的維護者，也可以先跟其開發群取得連繫。
解開壓縮檔後，先別急著要改裏面的檔案。因為，連套件名稱怎麼定，也絲毫不能馬虎。請先按照下列規則檢查您的源碼目錄名稱 (剛解出來的那個目錄) 是否正確。
範例：
demo-name-0.0.1-1ubuntu1
套件名稱-上游版本號-DEB版本號[註明字樣]次要版本號
套件名稱
一般來說，DEB 包要求套件名稱必須是少於二十個字的小寫英文字母，且如有分隔則加入“-”隔開。所以套件名稱是
demo-name，而不是demo_name 或 Demo-Name
等。至於要如何縮寫或用哪些字代表，可以跟開發群討論或參考一些普遍的規則，如：configure 用 config 甚至 conf 代替。
上游版本號
後面接的 0.0.1 為上游版本號 (upstream-version
number)，為該軟體開發群釋出的版本號，依你在官方站上抓到的源碼版本而定。此外，有些軟體並非遵循 x.y.z
的格式，而是以日期來定，如：20050713 等。新維護者手冊上是建議在前頭加上“0.0.”(即 0.0.20050713) 就可以了。
DEB版本號
ubuntu 前頭的 1 是 DEB 版本號 (Debian-reversion number)，是該套件的維護者(通常指 Debian
或 Ubuntu 正式人員)決定的。在上游版本號尚未更新時，每次維護者自行作的更改或補綴 (patch)，就利用這個數字來標記 (從 1
開始)。
註明字樣
註明字樣 (這只是我方便說明的稱呼，不是什麼專有名詞)
平常不太會加上去，只有在特別的情形下才有。如：該套件維護者同時維護兩種以上系統的套件，為了作區分而加註，像 Ubuntu 系統有一部分套件有
ubuntu 的字樣。或是該版本並非由維護者打包，有時也會加上打包者的 ID 作區分。
次要版本號
最後的次要版本號 (minor number，這也不是專有名詞)，是上述打包者和維護者不同時加的。這種情形在開發者參考文件中稱為 NMU
(Non-Maintainer
Uploads)。為了讓打包者也可以標記其修改歷程，通常會加註次要版本號，一方面也是提醒使用者這不是維護者打包的。值得一提的是，如果該上游版本尚
未有維護者版本，則該號碼使用 0.1 開始，即 demo-name-0.0.1-ubuntu0.1。
(範例中是 Ubuntu 系統的常見格式，Debian 系統大多都用 demo-name-0.0.1-1.1，上述特殊情形下會看到 demo-name-0.0.1-0.1 或 demo-name-0.0.1-packagerid0.1)
至於版本新舊該怎麼決定，對於套件能否正常更新與否也是很重要的。比較的過程是從左到右，套件名稱當然是一樣，接下來數字的部份以大者為新，字的部份以 ASCII 數值大者為新。注意，阿信 (asho) 兄在 2003.09.13 的線上 IRC 研討會有
提到一個可能犯的錯誤
：gv4l-2.0.2-asho1.deb 和 gv4l-2.0.2-2asho.deb
這兩個版本，照上述規則來講是前者新於後者。但事實上前者是指 2.0.2 版 asho 修改 1 版，後者是 2.0.2-2 版 asho
打包之意，這樣後者便應該新於前者。因此，打包時要小心避免這種混淆：)
首次“Debian化”
所謂的“Debian化”是指：一般來說，各種軟體會有各自一套路徑安排或設定等。若要以單一套件管理系統來應付各種需求，會過於複雜而容易產生問
題。如此一來，在不破壞軟體的功能前提下，先對它作標準化的動作，會讓套件管理變得簡單一些。當然，Debian 對於 DEB
套件也定出一套規則，如：二元檔通常放在 /usr/bin 或 /usr/sbin 下，而不是 /usr/local/bin 或
/usr/local/sbin 等。Ubuntu 基本上也遵循這套規則，而對其中一部分作了點修改，如：mo 檔 (語系檔)
的擺放位置等。將這些規則套用到要打包成 DEB 的軟體上，泛稱為“Debian化”。
看到 Debian 方針手冊 (Debian Policy Manual)
的人，可能會被一大堆的規定嚇到：)不過別擔心，dh-make
這個工具可以很簡單地幫助您作“Debian化”。它會先檢查您的套件名稱是否符合上個章節說的命名規則，然後依照一些給定的資訊，產生“Debian化
”相關檔案的範本。到時只要稍微修改範本，就可以完成打包的工作。
打包時建議使用一般使用者權限或善用 fakeroot，不要用真正 root 權限來做事情，除非是包好時要安裝作測試 -- 相信我，這樣可以省去很多麻煩：)
cd ~/demo-name-0.0.1-1ubuntu1/
dh_make (注意，這裡是“_”不是“-”)
Type of package: single binary, multiple binary, library, or kernel module?
[s/m/l/k] s
一般來說，功能不會太複雜的軟體，大多屬 single binary 之類。
以下的範例也將以 single binary 的情形探討。
Maintainer name : Demo User
Email-Address : demo@demo.org
Date : Wed, 13 Jul 2005 10:02:50 +0800
Package Name : demo-name-0.0.1
Version : 1ubuntu1
Type of Package : Single
Hit <enter> to confirm:
Done. Please edit the files in the debian/ subdirectory now. demo-name-0.0.1
uses a configure script, so you probably don't have to edit the Makefiles.
您會發現在 ~/ 下多了一個 demo-name-0.0.1-1ubuntu1.orig
的目錄，裏面放的是未修改的原始檔案。到時，如果使用者想要自行重新打包該套件，這個目錄可以供其重新修改或補綴。另外，在
demo-name-0.0.1-1ubuntu1 裡會多了個 debian 的目錄，您可以看到裏面有很多範本檔，這在下面幾個章節會詳細說明。
在進入下個章節之前，您是不是發現了哪個地方不太對勁？“套件名稱怎麼變成了 demo-name-0.0.1，而不是我本來要的
demo-name
呢？”在某些情況下，針對一些比較複雜的套件，維護者本身可能會頻繁地改版；或是開發群那邊大量小幅改版，造成同個上游版本號有一大堆版本。此時，用原定
套件名稱和上游版本號當作新的套件名稱，或許是個較好的選擇，像著名的 gcc 就有 gcc-2.95、gcc-3.3、gcc-3.4、和
gcc-4.0 等 (這裡舉 Ubuntu
上的為例)。一方面來說，使用者也可以自行決定，是否安裝兩套以上不同版本的套件，以便作相容性測試等。不過，如果您並不是打算如此，可以用 -p
參數強制決定套件名稱：
dh_make -p demo-name
Type of package: single binary, multiple binary, library, or kernel module?
[s/m/l/k] s
Maintainer name : Demo User
Email-Address : demo@demo.org
Date : Wed, 13 Jul 2005 10:02:50 +0800
Package Name : demo-name
Version : 0.0.1-1ubuntu1
Type of Package : Single
Hit <enter> to confirm:
Done. Please edit the files in the debian/ subdirectory now. demo-name
uses a configure script, so you probably don't have to edit the Makefiles.
嗯！它乖乖聽話囉：)其實 dh_make 還有很多種參數，可以自行 man dh_make 看看。
最後還有一點要提醒的：針對已經“Debian化”過的套件，是不能再下一次 dh_make 指令的。因為該套件將被當作未“Debian化”過的軟體處理，會造成打包時的錯誤。若要更新套件的版本號，請見「套件版本號更新」一節。
修改來源程式碼
通常這一步會執行到的機率很小，./configure 本身就會設定好要用的 Makefile。萬一運氣不好的話，您必須修改 Makefile.am 和 (或) Makefile.in，以便等下打包時能順利一些。當然問題不只這些，這裡並不多加詳述，請參考 新維護人員手冊的：第 3 章 - 修改來源程式碼。
debian/目錄中必備檔案
debian 目錄中有很多範本，包括選單檔、說明檔等。但是我們並不一定要全部都包進套件裡，必須要視情況作修改。一般來說，有三個基本要訣：
- 不會用到的範本就刪掉。
- 檔名後綴為 ex 的，如果我們要使用它，請先將檔名中的“.ex”去掉，例如：“menu.ex”改為“menu”。
- 範本中的空格和符號不要輕易更動，它們往往被用來作為分隔不同資訊的依據。有時更動之後，打包時會有無法辨別資訊的錯誤發生。
這個章節介紹的，是每個套件都必備的檔案。以下就針對各檔案扮演的角色分別作說明。
changelog
望文生義，這個檔案紀錄了不同版本間的沿革，用以告訴使用者新功能的增加或臭蟲的修正等。以下就 dh_make 的範本來討論。
範例：
demo-name (0.0.1-1ubuntu1) unstable; urgency=low
套件名稱 版本號 發行版 緊急程度
* Initial Release.
沿革紀錄
-- Demo User <demo@demo.org> Mon, 18 Jul 2005 22:46:32 +0800
維護者 Email 時間
- 發行版：一般來說，自行打包的通常為 unstable (或 experimental，更不穩定的版本)。
- 緊急程度：有 low、medium、high 和 emergency 等。用以指明將該套件加入 Debian / Ubuntu 測試版 (testing ) 的優先順序，或是該次版本沿革的重要程度。
- 沿革紀錄：如何寫出對使用者有幫助的紀錄， 開發者手冊：6.3 debian/changelog 最佳練習 已經有章節介紹，請先詳加閱讀。而且，這個部份您可以使用空行讓資訊更清楚明瞭。
control
這個檔案則包含許多安裝、升級時所需的資訊，如：相依性、分類、版本、套件說明等。
範例：
Source: demo-name
來源軟體名稱
Section: unknown
分類
Priority: optional
優先權
Maintainer: Demo User <demo@demo.org>
維護者
Build-Depends: debhelper (>= 4.0.0)
建立該套件所需的套件 (不是安裝該套件的相依性喔)
Standards-Version: 3.6.1
打包該套件所用的方針 (Policy) 版本，這是 Ubuntu Hoary 的值
Package: demo-name
套件名稱
Architecture: any
該套件適用的機器種類
Depends: ${shlibs:Depends}, ${misc:Depends}
安裝該套件的相依性
Description: <insert up to 60 chars description>
<insert long description, indented with spaces>
套件說明
- 分類：Debian 將所有套件都加以分類，以便使用者可以很快找到想要的套件。最上層的是 main
(自由軟體)、non-free (非自由軟體) 和 contrib (基於非自由軟體的自由軟體)。而 Ubuntu 則是分成 main
(Ubuntu 團隊維護的自由軟體)、restricted (該軟體的授權方式不是完全自由)、multiverse (非自由軟體) 和
universe (其他自由軟體)，請見 Ubuntu 官方說明。
然而其下還有子分類，如：“devel”-- 程式開發、“doc”-- 文件，“libs”-- 函式庫等。而“x11”是不屬於這些特殊分類的 X
視窗程式，通常您可以考慮將打包的套件納入“x11”，即把 unknown 改為 x11(當然，它必須有圖形介面)。
- 優先權：套件的重要程度。一般來說，我們打包的套件只要使用 optional 層級就可以了。
- 建立套件的相依性：當使用者想重新打包該套件時，所要滿足的相依性，即編譯該軟體所需的套件。如果要對某個套件作版本限制，可使用
<<、<=、=、>= 和 >> 等符號，如 libxft-dev (>=
2.0.0)。如果您不太清楚需要哪些套件，除了向該軟體開發群洽詢外，新維護人員手冊：4.1 “control”檔案 提供了一個方便的 script，可以列出所需的套件：
strace -f -o /tmp/log ./configure
# or make instead of ./configure, if the package doesn't use autoconf
for x in `dpkg -S $(grep open /tmp/log|\
perl -pe 's!.* open\(\"([^\"]*).*!$1!' |\
grep "^/"| sort | uniq|\
grep -v "^\(/tmp\|/dev\|/proc\)" ) 2>/dev/null|\
cut -f1 -d":"| sort | uniq`; \
do \
echo -n "$x (>=" `dpkg -s $x|grep ^Version|cut -f2 -d":"` "), "; \
done
- 該套件適用的機器種類：有 i386、powerpc 等。這裡建議保留 any，因為打包的工具會自動偵測維護者的機器種類並加以指定。
- 套件說明：套件說明主要是讓使用者能很快地知道該套件的功用，以及需不需要安裝該套件。如何寫出簡潔有力的說明，開發者手冊：6.2 debian/control 最佳練習 有詳細的說明。
copyright
這個檔案包含版權宣告和授權條款等等。
範例：
This package was debianized by Demo User <demo@demo.org> on
Mon, 18 Jul 2005 22:46:32 +0800.
It was downloaded from <fill in ftp site>
下載源碼的站台
Copyright:
Upstream Author(s): <put author(s) name and email here>
上游作者 (該軟體開發群)
License:
授權條款
<Must follow here>
- 授權條款：如果該軟體使用特殊的授權，請將其授權條款在此詳細註明。否則，一些通用的條款全文早在
/usr/share/common-licenses/ 目錄下提供：Artistic、BSD、GPL、GPL-2、LGPL、LGPL-2 和
LGPL-2.1。而 Debian
的方針中提到，當您打包的軟體是以上述條款授權時，請不要又一次將全文貼到這個區塊，取而代之的是加註類似這樣一段話 (以 GPL 為例)：
This package is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This package is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this package; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
02111-1307, USA.
On Ubuntu systems, the complete text of the GNU General
Public License can be found in `/usr/share/common-licenses/GPL'.
有時一個軟體是多個元件組成，若是每個元件有各自的授權條款，或是某些元件是其他作者的成果，這些都要交代清楚，免得日後產生爭議。如果您不是很清楚內容要怎麼寫的話，建議您向該軟體開發群洽詢：)
rules
這個檔案可以說是打包用的“Makefile”，供您指定如何處理該軟體直到打包完成。
範例：新維護人員手冊：4.4 “rules”檔案
關於裡面密密麻麻的指令到底作了些什麼，上述的連結裡有給出一個大概的說明。老實說，這裡並沒有一個很制式的寫法，端看您掌握該軟體到什麼樣的程
度，以及對每個指令的熟悉度。這些 dh_ 開頭的指令，都是 debhelper 這個套件提供的，man debhelper
就可以看到它們的功用。
針對這個部份，未來會考慮新增幾個個案討論或經驗談，來供各位看倌參考：)
debian/ 中其他檔案
除了上個章節中提到的必備檔案之外，其實還有不少其他的檔案，如：script 檔、選單檔等。維護者自己可以看情形作取捨，各個檔案的介紹請見 新維護人員手冊：第 5 章 - debian/中的其它檔案。
建立套裝軟體
O.K！修改好 debian 目錄下的範本後，終於要進入打包最緊張的一刻！
請回到您的源碼目錄下 (在這個例子中，是 ~/demo-name-0.0.1-1ubuntu1/ )，以一般使用者權限進行：
cd ~/demo-name-0.0.1-1ubuntu1/
dpkg-buildpackage -rfakeroot 建立套件
它會根據您的 rules 檔案，依序作建立相關檔案的動作。這過程會用 GnuPG 簽署 .dsc 和 .changes
兩個檔案，所以會問您兩次金鑰密碼。不過，所謂「天將降大任於斯人也，必先苦其心志」，事情往往沒有這麼簡單就落幕。一旦發生錯誤，您可能要重新修改
rules 檔，或是更大條的 -- 揪到一隻臭蟲！這就要聯絡該軟體開發群，看要怎麼治囉：P
(N 小時甚至 N 天過去 ...)
經過一番血淚打拼，它終於肯給過了！謝天謝地謝父母之後，請擦乾淚水，來檢查一下是否有以下檔案吧：)
- demo-name_0.0.1-1ubuntu1-1_i386.orig.tar.gz
源碼壓縮檔，檔名有個 orig 是 DEB 格式規定。
- demo-name_0.0.1-1ubuntu1-1_i386.dsc
該套件的總結 (summary)。除了來自 control 檔案的資訊外，還有 orig 檔和 diff 檔的 MD5 加總碼以供校驗。另外，還有 GnuPG 的簽署，使用者可以用您的公眾金鑰來確認發佈者。
- demo-name_0.0.1-1ubuntu1-1_i386.diff.gz
你對源碼所做的修改。而且，上述的源碼壓縮檔若是沒有遵照格式，建立 diff 檔時會發生錯誤喔！
如果使用者想要基於您打包的套件，自行修改並重新打包。通常都是先使用 apt-get source xxxx
(如果您使用來源站台發佈的話) 取得套件，而這三個就是 apt 會下載的檔案。它會先解開 orig 檔，然後用 dsc 檔校驗後，將 diff
檔所作的修改套用上去。另外，使用者也可以直接下載這三個檔，然後用 dpkg-source -x
demo-name_0.0.1-1ubuntu1-1_i386.dsc 達到同樣效果。
- demo-name_0.0.1-1ubuntu1-1_i386.deb
完整的二元 (binary) 套件檔。可以用 sudo dpkg -i xxxx 安裝或 sudo dpkg -P xxxx 移除它。
- demo-name_0.0.1-1ubuntu1-1_i386.changes
這個檔案描述了維護者所作的更動，在使用者透過來源站台安裝套件或取得源碼時會用到。同樣的，這也有 GnuPG 簽署，以供使用者確認發佈者。
在 新維護人員手冊：第 6 章 - 建立套裝軟體 中，還有介紹其他的方法，不過一開始還是建議您使用 dpkg-buildpackage：)
後續工作
先別急著要發佈套件，因為還有些後續工作要完成喔，再撐一下下吧：) 主要是檢查打包出來的套件合不合規定的格式等等，新維護人員手冊：第 7 章 - 檢查套裝軟體中的錯誤 有列出不少工具，這裡就幾個比較常用的跟大家介紹。
lintian 和 linda
這兩個工具主要是檢查您的套件是否符合 Debian 方針手冊上說的格式。這裡我們將用到剛剛產生出來的 .change 檔：
lintian -i demo-name_0.0.1-1ubuntu1-1_i386.changes
linda -i demo-name_0.0.1-1ubuntu1-1_i386.changes
前者會列出所有不符合方針手冊的部份，類似這樣：
W: demo-name: binary-without-manpage demo-name
N:
N: Each binary in /usr/bin, /usr/sbin, /bin, /sbin or /usr/games should
N: have a manual page
N:
N: Note, that though the `man' program has the capability to check for
N: several program names in the NAMES section, each of these programs
N: should have its own manual page (a symbolic link to the appropriate
N: manual page is sufficient) because other manual page viewers such as
N: xman or tkman don't support this.
N:
N: Refer to Policy Manual, section 12.1 for details.
N:
W: demo-name: zero-byte-file-in-doc-directory usr/share/doc/demo-name/NEWS.gz
N:
N: Package contains a file which is empty.
N:
W: demo-name: zero-byte-file-in-doc-directory usr/share/doc/demo-name/README
以 E 開頭的是錯誤訊息 (Error)，W 開頭的是警告訊息 (Warning)，而後面接 N
開頭的是對於該錯誤或警告的相關說明。針對錯誤當然是要回頭去修正，再重新 dpkg-buildpackage
一次；至於警告訊息的話，有時是因為軟體本身的關係，如：該軟體本來就沒有 manpage 之類的，維護者可以視情況忽略。
linda 作的事跟 lintian 很像，也會列出一些不合格式的地方，請根據回報訊息作修正。
pbuilder
至於 pbuilder 作的又是另一回事。它以類似映像檔的方式提供一個淨室 (chroot)
環境，讓維護者可以在裡面，試著從剛剛產生的檔案重新建立套件，以便檢查之前設定的建立套件相依性是否正確。這個動作十分重要！如此一來，維護者就不必為
不同架構疲於奔命，使用者可以為自己的機器量身打造套件 (基於該維護者的檔案)，我們來看看這麼棒的工具該怎麼用吧：) (以下大多需要 root
權限)
sudo pbuilder create
Ubuntu 的使用者則需要多費點功夫，請參考 UbuntuWiki：PbuilderHowto 建立映像檔。
sudo pbuilder build demo-name_0.0.1-1ubuntu1-1_i386.dsc
若有產生錯誤的話，可能要回頭去修改剛剛 control 檔中設定的相依性。一切順利的話，您可以在 /var/cache/pbuilder/result/ 找到輸出檔，而該檔案的所有者是 root。
如果您想讓該檔案的所有者為一般使用者，請以 pdebuild 代替 pbuilder build：
sudo pdebuild
- 更新 chroot 映像檔 (通常在您更新系統套件後)
sudo pbuilder update
至於其他更多的應用，請參考 pbuilder 使用者手冊。
上傳到發佈站台
套件版本號更新
一個有開發群在維護的軟體，不管是增強功能或是消滅臭蟲，版本更新是必經的過程！現在問題就來了 ─ 難道套件維護者每次都要照著這篇文章，重新來一輪完整的打包程序嗎？！
先別急著昏倒！這裡教你個偷吃步的方法，讓版本更新不再是噩夢！
假設新的上游版本號是 0.0.2，即新的源碼包為 demo-name-0.0.2.tar.gz，下載後的目錄關係如下：
┌──────────────────────────────┐
│ ～（或其他目錄） │
│┌────────────────┐ │
││ demo-name-0.0.1-1ubuntu1 目錄 │demo-name-0.0.2.tar.gz │
│└────────────────┘ │
└──────────────────────────────┘
demo-name-0.0.1-1ubuntu1 即我們之前在裡面下“dpkg-buildpackage -rfakeroot”指令的目錄，新的源碼包在它外面。
cd ~/demo-name-0.0.1-1ubuntu1/
uupdate -u -v 0.0.2-1ubuntu1 demo-name-0.0.2.tar.gz
其中 -v 參數可以讓我們強制指定套件版本號，以免 uupdate 自動偵測出來的不是我們要的，和 dh_make -p
是同樣道理。之後 uupdate 會幫我們新建一個 ~/demo-name-0.0.2-1ubuntu1 目錄，而之前的設定已經套用上去了。
只要到新目錄下的 debian 資料夾裡，視需要稍微修改一下 changelog 等檔案，即可建立套件：
cd ~/demo-name-0.0.2-1ubuntu1/
dpkg-buildpackage -rfakeroot
之後的處理就跟之前一樣，輕輕鬆鬆就更新套件版本號了呢：）
至於比較正規的作法，可以參考 新維護人員手冊的：9.3 新的上游版本 (實際的)
其他工具
- dh-make-perl - Create debian packages from perl modules
個案討論
參考文件
