制作DEB包的方法

转载请注明原文出处：http://blog.csdn.net/roddick621

由于个人水平有限，难免有很多不适当的地方，有什么翻译错误的，请多多指教^_^

原文地址

Chapter 1. Getting started The Right Way

这一章没做记录

Chapter 2. First steps

2.1 创建debian包的工作流

•     获取源码，源码通常都是一个压缩包 (package-version.tar.gz)
•     把debian打包所需要的信息写到debian目录中，然后把这份修改过的源码以3.0(quilt格式)打包
•     制作debian的二进制包，通常是以.deb为后缀。(package_version-revision_arch.deb)

    注意：在deb包中，包名和版本又下划线来分割，与还是源码包的时候不一样。package_version-revision_arch.deb中对应的值可以用以下的值来进行替换。package==>源码包名， version==>源码包的版本， revision==>Debian revision， arch==>包的适用架构。

2.2 选择你的程序

    如果你想制作一个包，首先你要决定你要制作一个什么软件的包。首先，你要确定你这个包有没有人已经制作好。如果有人已经制作好了，直接安装就好了。如果你找到的是一个已经没有人维护，但是还可以用的包，你可以接过来继续维护。

    如果你需要制作一个全新的包，并希望它出现在Debian中，请按照以下步骤进行：

• 你要确定你的软件有价值的，并且可用的。
• 你要确定这个包还没有人在做。
• 你的软件必须要有license
• 软件包不应该对Debian系统的安全造成威胁。

2.3 获取源码

     你可以直接获取已经做成tar包的源码，或者可以从VCS系统中获取(svn ,git, cvs)，然后用tar把源码压缩成一个包（压缩的时候可以加上--exclude-vcs，就可以忽略版本控制的文件)。接着你应该仔细的阅读以下里面的一些说明文件，起码要知道应该怎么去编译和安装。

     开始打包时，源代码目录应该是绝对干净的（原始）的，或者直接使用刚刚解压包得到的。

2.4 简单的编译

    一个简单的程序通常包含一个Makefile，你可以调用make去对它进行编译和make install进行安装。有些还包含了make check，用来检查刚刚编译出来的文件有没有问题。

2.5 主流的编译方法

    通常是使用autotools(autoconf, automake ,libtool和gettext)工具来支持多平台。工具的具体方法这里不作介绍了。

2.6 软件包的名称和版本

    软件的包名只能够包含小写字母(a-z)，阿拉伯数字(1-9)，还有加号(+)，减号(-)，还有点(.)。而且长度不能小于2，推荐长度是小于30个字符。

    包的版本号只能够包含字母数字(a-zA-Z1-9)，还有加号(+)，减号(-)，还有点(.)，波浪号(~)。

    如果上游的源码版本号不是用普通的版本号（2.30.32），而是用（11Apr29）的，或者一些CVS系统生成的随机字符的话，应该要把这些字符从版本号中删除，但可以把它记录在debian/changelog中。

    deb包的版本号对比可以用dpkg的命令来进行对比：

dpkg --compare-versions vers1 op vers2

    版本对比的规则如下：

• 字符串从头到位进行比较
• 字母要比数字要大
• 数字会作为整数进行比较
• 字母的比较是根据ASCII的顺序进行比较
• 特殊的字符加号(+)，减号(-)，还有点(.)，波浪号(~)规则如下：0.0 < 0.5 < 0.10 < 0.99 < 1 < 1.0~rc1 < 1.0 < 1.0+b1 < 1.0+nmu1 < 1.1 < 2.0

2.7.设置dh_make

    设置两个环境变量：$DEBEMAIL和$DEBFULLNAME 

    分别用于给打包程序识别你的Email和名字。

    你可以在~/.bashrc中设置好，并且把它export出来。

2.8初始化非自己的包

    很多时候一些源码都是直接从网上下载下来的，如果你想通过这些源码生成一个新的的deb包，你可以使用dh_make来初始化这些源码，具体操作如下。

$ cd ~/gentoo
$ wget http://example.org/gentoo-0.9.12.tar.gz
$ tar -xvzf gentoo-0.9.12.tar.gz
$ cd gentoo-0.9.12
$ dh_make -f ../gentoo-0.9.12.tar.gz

    这里会提示你选择生成包的类型，根据自己的需要选择就行了。这里选择的是s。然后观察上一级目录，会生成一个新的文件，名字为：

    gentoo_0.9.12.orig.tar.gz

    观察这个包，有两个特点，名字和版本号之间是以下划线_来分隔的，还有就是在.tar前面加入了.orig

    你还应该注意到在源码目录的debian文件夹下有很多临时文件，他们的作用会在第四和第五章进行解析。你也应该知道，打包过程不可能完全自动化，你应该修改源码以适应Debian。然后，你就可以适当的方法去创建一个deb包，检测和上传软件包。这些步骤在后面都会解析。

    如果你在修改过程中不小心删除或者破坏了某些模版文件，你应该是用dh_make --addmissing来将其还原。

    升级软件包的过程可能会比较复杂，如果是刚开始学，应该用一个新的包。

   

2.3.初始化本地的包

    如果有一个包是你自己管理的，或者是只有你自己去使用的话，你可以使用不同于上面的方法去初始化这个包，具体的命令如下：

$ cd ~/mypackage-1.0
$ dh_make --native

    跟上面不同的地方就是，这个命令只是不会生成一个tar包。剩下的几乎都是一样的。

Chapter 3. Modifying the source

3.1-3.2主要是讲解如何修改修改源码的，因为这部分主要是利用quilt来修改源码的bug，对于打包来说意义不大，所以就不详细说了。

3.3.把软件安装到目标路径

    很多第三方的软件会默认安装到目录/usr/local下。

    但是在Debian，这是由系统管理员保留给私人使用的，所以必须使用/usr/bin来代替/usr/local/bin，服从FHS

    通常是使用make来编译，make install来安装程序到目标目录。Debian为了提供个pre-build的可安装的包，修改了编译包的机制，使其可以安装到一个临时目录而不是最终的目录。

    对于普通的程序安装有两个差异，一个是Debian的包管理，另外一个是可以透明的通过debhelper的db_auto_configure和db_auto_install来解决安装的问题。不过它需要满足一下两个条件：1.Makefile满足GNU并且支持变量$DESTDIR。2.源的存放必须准从FHS

    很多程序都遵从GNU的约定，所以他们使用autoconf很轻易地打成包。大概有90%的机会，debhelper可以在一个没有修改过的源码里面正常工作，所以打包并没有想象中的那么难。

    如果你想去修改Makefile，你应该小心地支持$DESTDIR。虽然这个值木有添加，默认为空，但是会在安装的时候都加入到每个文件的目录名前面。这个打包脚本会把$DESTDIR设置为一个临时目录。

    如果从一个源码包中生成一个二进制的包，dh_auto_install会把临时目录设为debian/package。当别人安装你的包的时候，在debian/package中的所有文件都会被安装到别人的机器上面。唯一不同的地方就是dpkg会把文件安装到根目录下而不是你的工作目录。

    记住，即使你的程序可以安装在debian/package，但是它安装在root目录下还是要能够正确运行的。所以你不能够在代码里面把路径写死。

    当你修改完代码后，应该用调用dqulit来生成补丁，并把新补丁增加到debian/patches目录中。

3.4.不一样的库名称

    这是一个常见的问题。相同的库在不同的平台下面会不尽相同，所以Makefile里面如果指定错了库名，只需要修改一下就可以了。

Chapter 4. Required files under the debian directory

    在源文件下有一个新的子目录叫debian的，这里包含了一系列的文件，这些文件可以供我们根据我们的需要进行修改，然后控制包的的一些行为。里面最重要的文件主要是control，changelog，copyright和rule，他们是每一个包都需要的。

4.1.control

    这里包含的信息是给dpkg , dselect, apt-get, apt-cache, aptitude等包管理工具去控制包的。它们会在第五章里面进行定义  。下面是一个由dh_make创建的一个control文件。

  Source: gentoo        
  Section: unknown      
  Priority: extra  
  Maintainer: Josip Rodin <joy-mg@debian.org>
  Build-Depends: debhelper (>=9)                      
  Standards-Version: 3.9.4      
  Homepage: <insert the upstream URL, if relevant>      
 
  Package: gentoo        
 Architecture: any      
 Depends: ${shlibs:Depends}, ${misc:Depends}           
 Description: <insert up to 60 chars description>       
  <insert long description, indented with spaces>       

    1-7行是源码包的控制信息，9-13行是二进制包的控制信息（也就是声称之后的安装包了），每个域的说明都已经在上面解析了，不过不是很详细，详细的请查看原文档。

1. 源码包的包名
2. 是该源码包要进入发行版的那个分类中，例如：main,non-free,contrib,admin,devel,doc,libs,mail.net,x11，还有很多没有例举出来
3. 告诉用户这个安装包的重要性 ，optional与required,important,standard能并存， extra 与non-extra不能并存
4. 管理员的名字和Email。这里一定要有一个合法的Email地址，因为因为一旦有bug，bug管理系统就会给你发送邮件通知你。这里要避免使用逗号，&号和句号。
5. 生成安装包所需要依赖的包，你可以增加多一行Build-Depends-Indep来指定更多的依赖文件。例如gcc和make这些工作，已经被隐含的包含在essential的包里面了。如果你还需要其他包的话，可以把它们添加到这行。如果是依赖多个包，用分号把他们隔开。对于所有需要用dh命令来打包的包来说，都需要加上debhelper (>-9)去满足Debian Policy的clean需求。如果生成的二进制包是有Arahitecure:any的，所以来的包基本上都是写在Build-Depeds里面的，很少写在Build-Depends-Indep。如果是生成的二进制包有Architecure:all的话，在Build-Depends中只记录为了满足Debian Policy requirement的clean目标的依赖，其他的依赖都可以写到Build-Depends-Indep中。如果你不知道应该用那个，则应该使用Build-Depends以保证安全。
6. Debian Policy Manual的版本号
7. 你的软件的主页
8. 
   
9. 二进制包的名字，通常和源码包保持一致
10. 描述你的包是为了那个架构而打生成的。 any:与架构有关，普遍是跟编译的语言有关 。 all:与架构无关，大多这样的包是包含了文档，图片还有一些由解析性的语言编写的脚本。如果我们的程序是用C语言写的话，我们可以不用管这个字段，应该dpkg-gencontrol会根据实际情况来填写一个正确的值。
11. debian包管理系统最强大的功能之一。每个软件包都可以和其他软件包有各种不同的关系。除了Depends之后，其他关联的还有Recommands,Suggests,Pre-Depends,Breaks,Conflicts,Provides和Replaces.包管理工具通常都是用相同的方法去处理这些关系的，如果不是的话，它会进行解析的。
12. Depends ==> 此软件包仅当它依赖的软件包均已安装后才可以安装，此处写明你的程序所必须的软件包。 Recommends ==》不是严格要求的，不过你的程序通常都会用到。apt-get和aptitude在安装的时候会提示把这些依赖一起安装，但是dpkg则不会。 Suggests ==》不是一定需要的，但是有的话能使你的程序更加完美。aptitude会提示，dpkg和apt-get则不会提示。 Pre-Depends==》比Depends抢，软件包在预依赖的软件包已经安装并且正确配置后才可以安装，所以使用此项时应该十分谨慎。 Conflicts==》仅当所有冲突的软件包都已经被删除后才可以安装。 Breaks==》当安装完这个包，就会破坏列表中的包。它通常是指定同一个软件的旧版本。通常是高级包管理工具用来更具列表中的软件。 Provides==》一些包可以从virtual-package-names-list.txt.gz后去多个可选的虚拟名字，如果你的虚拟包包含一个函数，你就应该使用它（？不懂）  Replaces==》当你的程序要替换其他软件包的某些文件，或是完整地替换另一个软件包（与Conflicts一起用）。列出软件包中的某些文件会被你的软件包所覆盖。  以上所有的域都有相同的语法，当依赖的包只需要二选一的时候，可以通过管道符|来隔开两个包。这里还可以限制每个依赖包的版本，可以使用<<,<=,=,>=,>>来表示大于，大于等于，等于，小于等于，小于。例子：libbbar1 (=1.3.4)。 最后需要了解的是类似${shlibs:Depends} 这样的用法，${shlibs:Depends}是负责计算出你你ELF文件和动态库所依赖的所有文件。
13. 简短的描述
14. 这个包的详细描述，不过需要注意的是，每一行的第一列都需要为空，并且不能有空行，但是你可以输入一点去模拟这是一个空行。

前端软件例如aptitude在排列包或者选取默认包的时候，会用到Section和Priority。一旦你把包传上去Debian后，这个包的维护人员就可以修改这两个值，在这种情况下，你会收到邮件的通知。

在Depends字段中，你还需要知道的就是${shlibs:Depends} , ${perl:Depends} ,  ${misc:Depends}

• dh_shlibdeps(1) 会用来找出二进制包所依赖的动态库，它会为每个二进制包生成一个列表，列表中包含了该包所以来的文件和动态库。这是用来取代${shlibs:Depends}的
• dh_perl(1) 这个是用来找出perl或者perlapi的依赖文件的。它是用来取代${perl:Depends}的
• 一些debhelper命令会导致生成的包增加一些依赖，所有这名都会未二进制包生成一个依赖列表。这是用来取代${misc:Depends}的
• dh_gencontrol(1)是为每个二进制包生成DEBIAN/control的。它用于取代${shlibs:Depends}, ${perl:Depends}, ${misc:Depends}等等

4.2.copyright

    这个文件主要包含的是软件的版权信息和许可证信息。dh_make会自动帮你生成一个模板。你可以使用dh_make --copyright gpl2去生成一个基于GPL-2的模板。

4.3.changlog

    这是一个必要的文件。它是用于被dpkg和其他程序来获取软件的版本号，修订号，发布状态和urgency。对于你来说，这个文件同样重要，因为它可以记录下你所做的更改。它可以帮助其他用户知道你的包更新了什么东西。他会保存在/usr/share/doc/<pkgname>/changlog.Debian.gz。

  gentoo (0.9.12-1) unstable; urgency=low       （包含了包名，版本号，修订号和urgency。这里的名字必须和源码包的名字相同。发布状态应该为unstable，为了防止包在未完全开发好的情况下上传，可以把发布状态设置为UNRELEASED）

   * Initial release (Closes: #nnnn)  <nnnn is the bug number of your ITP>      （3-5行是修改的记录）

  -- Josip Rodin <joy-mg@debian.org>  Mon, 22 Mar 2010 00:37:31 +0100

4.4.rules

    现在我们去看dpkg-buildpackage会用来控制生成包的文件rules。这个文件实际上是一个Makefile文件，但是和源码的Makefile不是同一个。在debian里，这个文件与其他文件不同，它被设置为可执行文件。

4.4.1.Target of the rules file 

    每一个rule文件都像其他Makefile那样，包含了一些规则，这些规则主要是定义了一个目标和如何生成这个目标。规则的格式和Makefile的一样，目标在一行的开头，然后接下来的行在行头用TAB键填充，然后写入生成目标的方法。空行或者行头用#注释的行会被忽略。

    你想调用那个目标，你就把目标加作为命令行的参数就可以了。

rules的格式与普通的Makefile文件一致，有需要了解的可以直接去找关于Makefile的文章。

    下面的是对Makefile目标的一些简单的描述：

    clean（必选）：删除编译过程中生成的文件和一些没用的文件

    build（必选）：从源码编译生成目标程序和格式化的文档

    build-arch（必选）：从源码编译出跟平台相关的程序

    build-indep（必选）：从源码编译出跟平台无关的程序

    install（可选）：安装debian目录下的所有二进制包。如果定义了，binary*这类的目标将会依赖它。

    binary（必选）：生成所有二进制包（binary-arch和binary-indep的有效组合）

    binary-arch（必选）：在父目录生成一个跟平台相关的二进制包

    binary-indep（必选）：在父目录生成一个跟平台无关的二进制包

    get-orig-source（可选）：从网上获取最新版本的源码包

4.4.2 Default rules file

    dh_make会生成一个简单的但是很有用的rules文件

#!/usr/bin/make -f
# -*- makefile -*-
# Sample debian/rules that uses debhelper.
# This file was originally written by Joey Hess and Craig Small.
# As a special exception, when this file is copied by dh-make into a
# dh-make output file, you may use that output file without restriction.
# This special exception was added by Craig Small in version 0.37 of dh-make.

# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1  把这行打开可以让每一个dh命令的输出都打印出来，或者通过export DH_OPTIONS=-v参数

%:
        dh $@

    12-13行是使用模式规则去调用一些隐含的规则。百分号意味着是“所有规则”，他是通过指定目标名来条用dh命令。dh命令是一个包装好的脚本，它可以根据参数来调用一系列适当的dh_*命令。

    debian/rules clean调用dh clean, 它会依次执行以下的命令:

dh_testdir
dh_auto_clean
dh_clean

    debian/rules build调用dh build，它会依次执行以下的命令:

dh_testdir
dh_auto_configure
dh_auto_build
dh_auto_test

    fakeroot debian/rules binary调用fakeroot dh binary，它会依次执行以下的命令:

dh_testroot
dh_prep
dh_installdirs
dh_auto_install
dh_install
dh_installdocs
dh_installchangelogs
dh_installexamples
dh_installman
dh_installcatalogs
dh_installcron
dh_installdebconf
dh_installemacsen
dh_installifupdown
dh_installinfo
dh_installinit
dh_installmenu
dh_installmime
dh_installmodules
dh_installlogcheck
dh_installlogrotate
dh_installpam
dh_installppp
dh_installudev
dh_installwm
dh_installxfonts
dh_bugfiles
dh_lintian
dh_gconf
dh_icons
dh_perl
dh_usrlocal
dh_link
dh_compress
dh_fixperms
dh_strip
dh_makeshlibs
dh_shlibdeps
dh_installdeb
dh_gencontrol
dh_md5sums
dh_builddeb

    fakeroot debian/rules binary-arch调用fakeroot dh binary-arch，它执行的命令的顺序和fakeroot dh binary一样，但是每个命令都添加了参数-a

    fakeroot debian/rules binary-indep调用fakeroot dh binary-indep，它执行命令的顺序基本上和fakeroot db binary一样，但是不包含dh_strip, dh_makeshlibs和dh_shlibdeps，并且每条命令都添加了参数-i

    dh_*命令大部分都可以直接从它的名字知道它的作用，但是在一个基于Makefile的典型打包环境之，还是有几个是值得注意一下的，特意在这里给出了简单的解析，

    dh_auto_chean通常会调用make distclean假如Makefile中存在distclean这个目标。

    dh_auto_configure通常会调用./configure +参数 当文件configure存在的时候。

    dh_auto_build通常会执行make来执行Makefile的第一个目标。

    dh_auto_test通常会执行make test加入Makefile中有test这个目标。

    dh_auto_install通常会执行make install假如Makefile中有install这个目标。

所有需要用到fakeroot的目标都会包含dh_testroot，它是用来把自己伪装成为一个root用户。

最重要的一点就是又dh_make生成的rules中的内容只是一些建议，它对于大部分包来说是可以用的，但是对于一些复杂的包来说，就需要你自己去定制了。

虽然install不是必须的，但是也是支持的，fakeroot dh install 的行为跟fakeroot dh binary有点类似，但是它会在执行完dh_fixperms后就停止执行了。

4.4.3.Customization of rules file

    有很多方法来定制使用dh命令创建新的的rules文件。

    dh $@命令可以根据以下的方法来自定义：

•      增加对dh_python2命令的支持（推荐）：

         ----在Build-Depends中包含python

         ----使用dh $@ --with python2

         ----使用python的框架去处理Python的模块

•     增加对dh_pysupport命令的支持（不推荐）：

         ----在Build-Depends中包含python-support

         ----使用dh $@ --with pysupport

         ----使用python-support的框架去处理Python的模块

•     增加对dh_pycentral命令的支持（不推荐）：

         ----在Build-Depends中包含python-central

         ----使用dh $@ --with python-central

         ----这会使dh_pysupport命令无效

         ----使用python-central的框架去处理Python的模块

•     增加对dh_installtex命令的支持：

         ----在Build-Depends中包含tex-common

         ----使用dh $@ --with tex

         ----注册类型为1的字体，断句样式和TeX的格式

•     增加对dh_quilt_patch和dh_quilt_unpatch命令的支持：

         ----在Build-Depends中包含quilt

         ----使用dh $@ --with quilt

         ----这是quilt 1.0格式的包打补丁，3.0格式的不需要，补丁文件放在debian/patches中

•     增加对dh_dkms命令的支持：

         ----在Build-Depends中包含dkms

         ----使用dh $@ --with dkms

         ----这是使用内核模块去处理DKMS

•     增加对dh_autotools-dev_updateconfig和dh_autotools-dev_restoreconfig命令的支持：

         ----在Build-Depends中包含autotools-dev

         ----使用dh $@ --with autotools-dev

         ----更新和恢复config.sub和config.guess

•     增加对dh_autoreconf和dh_autoreconf_clean命令的支持：

         ----在Build-Depends中包含dh-autoreconf

         ----使用dh $@ --with autoreconf

         ----在编译之后更新和还原GNU Build System文件

•     增加对dh_girepository命令的支持：

         ----在Build-Depends中包含gobject-introspection

         ----使用dh $@ --with gir

•     增加对bash completion特性的支持：

         ----在Build-Depends中包含bash-completion

         ----使用dh $@ --with bash-completion

         ----这是通过配置文件debian/package.bash-completion来安装bash completions

    很多被dh命令调用的dh_*命令都可以通过debian文件夹内的相应的配置文件来定制的。

    你可能需要通过带参数的dh命令来调用dh_*命令，或者调用额外的命令，或者直接跳过他们。在这样的情况下，你可以在rules文件下生成一个新的目标override_dh_foo来改变dh_foo命令。

    请注意dh_auto_*命令会因为要考虑到各种各样的条件，所以倾向于做比上面讨论过的操作更多的操作。但是如果用override_dh_*去简化它的话，并非一个好的注意。

    这里需要注意的是，dh_auto_*命令总是希望能做得更多，所以它需要考虑到各种各样的条件。但是用override_dh_*来简化它并不是一个好的做法（除了override_dh_auto_clean)，因为它可能会忽略了debhelper的一些好的功能。

    例如，如果你想使用autotools把系统的配置数据的保存目录从/etc改成/etc/gentoo的话，你可以把dh_auto_configure中传给./configure命令的参数--sysconfig=/etc重写了。

override_dh_auto_configure:
        dh_auto_configure -- --sysconfig=/etc/gentoo

在--后面的参数是会追加到默认的参数后面，用来覆盖默认的参数的。如果要保留原有参数，只是重写sysconfig参数，则使用dh_auto_config会比直接调用configure命令会好。
如果源码中的Makefile需要你在make的时候指定build作为目标才可以编译的话，你可以用下面的方法重写：

override_dh_auto_build:
        dh_auto_build -- build

这里可以保证$(MAKE)除了只是增加了build作为参数外，其他参数都是用dh_auto_build的默认参数。

如果在源码中指定清理操作，不是用clean或者distclean，需要指定packageclean目标才可以清理源码，你可以使用下面的方法：

override_dh_auto_clean:
        $(MAKE) packageclean

如果你的Makefile中包含了test这个目标，但是在打包的过程中不想执行这个目标的话，可以使用一个空的override_dh_auto_test来实现：

override_dh_auto_test:

如果源码有一个与众不同的changlog文件FIXES，dh_installchangelogs默认情况下是不会安装它的。dh_installchangelogs命令需要在参数中指定FIXES才可以。

override_dh_installchangelogs:
        dh_installchangelogs FIXES

如果你需要使用新的dh命令，应该的使用4.4.1中明确提到的目标名字作为目标，而不是自己新增加的，因为新增加的可能会造成额外的影响，但是我们可能很难去发现。如果可以的话，应该尽量把目标限制在override_dh_*的目标中，并且保证它们是完全独立的。

Chapter 5. Other files under the debian directory 

    如果需要控制打包过程中debhelper的行为，你应该通过在debian的目录下放置一些可选的配置文件来实现。这一章会介绍里面的每个文件的作用和格式。

    dh_make命令会在debian文件夹内生成一些模板的配置文件，大多数的后缀名是.ex的。有一部分是用二进制报的名字做为前缀的。

    一些被debhelper用的配置文件或许没有被db_make生成，在这种情况下，你需要手动生成一个并且编辑它。

如果你需要debian目录中的所有文件都打到包里面，就应该做到下面的几条：

• 如果有.ex或者.EX后缀的文件，删除他们的后缀（即重命名去掉后缀）
• 用二进制的包名取代配置文件中的“package”
• 根据你的需要修改模块文件
• 删除你不需要的配置文件
• 根据需修改control文件
• 根据需要修改rules文件

所有的debhelper配置文件如果没有以"package"为前缀的，例如install，它是为第一个二进制包所用的。如果这次打包过程中会生成超过一个包，则它们的配置文件一定要以包名作为前缀，例如：package-1.install,  package-2.install。

5.1.README。Debian

    记录你的包与官方包之间额外的细节的或者不同之处的文件。

    

gentoo for Debian
-----------------
<possible notes regarding this package - if none, delete this file>
 -- Josip Rodin <joy-mg@debian.org>, Wed, 11 Nov 1998 21:02:14 +0100

    如果没有东西需要记录，可以删除。

5.2.compat

     定义debhelper相容性的等级，你可以设置它为9级。

echo 9 > debian/compat

5.3conffiles

    最令人气愤的东西莫过于当你花费了大量时间去修改一个程序，但是你的改变只是为了一个小小的升级。Debian可以解决这个问题，它通过把需要保存的配置文件保存到conffiles。当你升级一个包，你会被提示时候保留旧的配置文件。

    dh_install(1)会自动把/etc目录下面的文件添加到conffiles，所以你不需要手动去指定它们。对于大多数的包来说，只要在/etc目录下面的文件才需要添加到conffiles文件中，所以 这个文件可以不需要。

    如果你的程序使用的配置文件被它自己重写过，最好的还是不要把它加入到conffiles中，因为dpkg一定会提示用户去验证一下被修改了那些东西。

    如果你打的包所用的/etc下的配置文件是会被每个人户都修改的，这里会有两个比较流行的方法，既不需要把它们加到conffiles，也不需要用到dpkg。

•     由维护脚本，把存在/var目录下的文件做一个软连接到/etc目录下。
•     由维护脚本在/etc目录下生成一个文件。

    更多关于维护脚本的信息，可以看5.19节。

5.4package.cron.*

    如果你的包需要需要定期执行一下操作的话，你可以用下面说到的文件去设置它。 你可以设置每小时，每天，每日，每周，每月或者你喜欢的任何时候。   

•     package.cron.hourly : 会安装到/etc/cron.hourly/package，每个小时运行一次
•     package.cron.daily : 会安装到/etc/cron.daily/package，每日运行一次
•     package.cron.weekly : 会安装到/etc/cron.weekly/package，每周运行一次
•     package.cron.monthly : 会安装到/etc/cron.monthly/package，每月运行一次
•     package.cron.d : 会安装到/etc/cron.d/package, 会据该文件内设置的周期来运行

    除了package.cron.d要根据crontab的根式来写意外，大部分这些文件都是shell脚本。

5.5.dirs

    这个文件具体指明了一些我们需要的，但是在安装的过程中(又dh_auto_install调用make install DESTDIR=...)没有生成的文件夹。这意味着Makefile中没有满足我们的需要，出现了一些问题。

    在install文件中列出的文件，不需要先创建文件所存在的目录（系统会自动创建）。

    最好的方法就是你先安装一下这个包，如果是有问题了，在使用dirs这个文件。

    如果你遇上了错误，最好是第一部就直接运行安装。在dirs文件内的目录名前面没有斜杠符号的（即不是绝对路径）

5.6.package.doc-base

    如果你的软件包中除了用户手册和info page意外，还有一些文档的话，你应该使用doc-base文件把这个文件注册到系统中，让用户可以用dhelp(1),dwww(1)或dcocentral(1)这些命令来找到它。

    这通常包含HTML， PS和PDF文件，放置在/usr/share/doc/packagename/中。

下面是gentoo包的gentoo.doc-base文件：

Document: gentoo
Title: Gentoo Manual
Author: Emil Brink
Abstract: This manual describes what Gentoo is, and how it can be used.
Section: File Management
Format: HTML
Index: /usr/share/doc/gentoo/html/index.html
Files: /usr/share/doc/gentoo/html/*.html

关于这个文件格式的更多信息，可以查看/usr/share/doc/doc-base/doc-base.html/index.html。

5.7.docs

    这个文件制定了我们使用dh_installdocs(1)安装到临时目录的文件名    

    默认情况下它会把代码目录顶层所有名为BUGS、README*、TODO等的文件都加入到其中。

5.8.emacsen-*

    如果你的软件包提供可以在安装时编译为字节码的Emacs文件，你可以使用这些文件设置。

    它们会被dh_installemacsen(1)安装到临时目录。

    如果你不需要这些，就删除它们。

5.9.package.examples

    dh_installexamples(1)会将列出的文件和目录作为示例文件安装。

5.10.package.init 和 package.default

    如果你的程序是一个需要在开机就启动的daemon，你显然唔使我一开始的建议，不是吗？

    package.init这个文件会会安装为/etc/init.d/package，用于启动和停止daemon进程。它相当于dh_make命令提供的init.d.ex文件。你可以重命名和编辑它，在编辑的时候应该确保它包含了一个LSB的兼容的头。它会被dh_installinit安装到临时目录。

    package.default这个文件会安装为/etc/default/package，这个文件是被init脚本设置默认值的。这个文件通常用于禁用守护进程，或者设置默认的参数或者超时时间。如果你的init脚本有一定的可配置特性， 你可以在这里进行配置，而不是在它自己的init脚本设置。

    如果是源码包中已经提供了一个init脚本，你可以自己选择使不使用它。如果你不想使用源码提供的init文件，那么你必须自己重写一个了。即使源码包中提供的看起来没什么问题，并且已经安装到了合适的地方，但是你依旧需要去创建rc的软连接（在/etc/rcX.d中，控制开机启动）。创建软连接你可以通过重写dh_installinit来实现：

override_dh_installinit:
        dh_installinit --onlyscripts

5.11.install

    如果在执行make install的时候，有一些文件不被安装到包的临时目录中，但是你又是需要这些文件的话，你应该把这些需要加进去的文件的文件名写入到install文件中。他会被dh_install(1)命令所安装。不过你首先要确定你要安装的文件是不是应该又这个脚本去控制，例如文档文件应该又doc文件去控制，而不应该写到这个文件中。 

    在这个文件中，一个文件对应一行，格式为源文件（相对于最顶层的编译目录），然后空格，最后加上安装目录（相对于安装的目录）。加入src/bar这个文件需要安装，那么install文件里面应该这样写：

src/bar usr/bin

    这意味着当这个包被安装完之后，bar会在/usr/bin/bar中。

    只有安装的相对目录没有变化的情况下，写在install才会写入文件名。这样的格式通常用于把一个很大的包拆分为几个小包，然后把它的配置文件改成package-1.install， package-2.install等。

5.12.package.info

    如果你的软件包含info package，你应该把它写入到package.info文件中。

5.13.package.links

    包维护人员需要在创建包的目录中增加连接的话，你应该把这个连接的完整路径和目标路径写入到package.links文件中，然后让dh_link(1)命令去安装到真正的目录中。

5.14.{package.,source}/lintinan-overrides

    如果Debian的策略允许lintian报告一个错误的诊断情况时，你可以用package.lintian-overriades或者source/lintian-overrides去把这些错误通知给禁止了。更多的信息请看/usr/share/doc/lintian/lintian.html/index.html，并且不要滥用这个工功能。

5.15.manpage.*

    你的程序应该有手册页，如果没有，你应该生成它。dh_make命令会生成一些手册文件的模板。最后应该删掉一些没有用的模块。

    5.15.1.manpage.1.ex

        这个文件是用nroff写的。

    5.15.2.manpage.sgml.ex

        这个文件是用SGML写的。

    5.15.3.manpage.xml.ex

        这个文件是用XML写的

5.16.package.manpages

    如果你的包包含手册页，你应该把他列在package.manpages文件中，并使用dh_install命令去安装它。

    把docs/gentoo.1作为gentoo包的手册页安装到系统中，应该创建gentoo.manpages并写入

docs/gentoo.1

5.17.menu

    X Windows系统用户通常有窗口管理器，并且带有可定制的菜单用于启动程序。如果它们安装了Debian的menu包，整个系统中所有已安装软件的一系列菜单将会被自动创建。

    这里有一个又dm_make创建的默认文件：

?package(gentoo):needs=X11|text|vc|wm \
        section=Applications/see-menu-manual\
        title=gentoo command=/usr/bin/gentoo

冒号后的第一个域是needs，它指定了程序需要何种界面。修改此处为列出的选项之一，例如X11或text。

下一个域是section，它指定了菜单和子菜单应该出现在什么地方。

title域是程序的名称，它可以用大写字母开头，只需保证它不是很长。

最后的command域是运行此程序时使用的命令。

你还可以添加其他的域，例如longtitle, icon, hints等等，详细信息可以看dh_installmenu(1), menufile(5), update-menus(1)。

5.18.NEWS

dh_installchangelogs(1)命令会安装这个文件。

5.19.{pre,post}{inst,rm}

    postinst,preinst,postrm和prerm文件被称为维护脚本。这些脚本被放置在包里面的控制区内，并且被dpkg用来控制安装，升级和删除。

    作为一个新手，你应该避免手动地去修改这些维护者脚本，更多的信息你可以查看 这里，还有应该仔细看一看dm_make生成的一些例子。

    但是如果你坚持去做，你应该保证他们不单止可以安装，升级，还需要删除和彻底清除。

    升级到一个新的版本应该是安静的和不需要交互的（即用户不知道程序已经通过升级来修复了部分Bug，并且为用户提供了新的特性）。

    当一个包升级的时候需要交互（例如配置文件分布在不同的home目录并且有完全不同的结构）， 你可以考虑作到最差的情况下应该提供返回一个安全的状态（例如禁用服务），并提供适当的文件所需的策略去解决问题（ README.Debian和NEWS.Debian ）。 不要让用户通过维护脚本调用debconf来打扰用户去升级软件。

5.20.package.symbols

    讲动态库打成一个包对于初学者来说并不容易，因为应该尽量避免。因此，如果你的包包含了动态库，你应该有debian/package.symbols文件。

    这个文件主要是用来管理动态库之间的兼容性的。

    

5.21.TODO

    dh_installdocs命令会安装它。

5.22.watch

    用于uscan的manpage。

5.23.source/format

    在debian/source/format中只包含一行，写明了此源码包的格式(查看dpkg-source(1))获得完整列表。在squeeze后，它应该是以下两者之一：

• 3.0 (native) - Debian native 软件
• 3.0 (quilt) - 其他所有软件

    全新的3.0 (quilt)源代码格式将所有修改都用quilt补丁系列记录到debian/patches。这些修改会在解压源代码包时自动应用。 Debian修改保存于debian.tar.gz归档文件，其中包含了整个debian目录。这个新格式直接直接添加例如PNG图标等的二进制文件。

    dpkg-source解压3.0 (quilt) 格式的源码包时会自动应用所有列于debian/patches/series的补丁，你可以使用--skip-patches选项避免在解压后自动应用补丁。

5.24.soruce/local-options

    如果你希望使用版本控制系统(VCS)时，你可以创建一个分支(例如叫做upstream)来跟踪上游代码，和另一个分支(对于Git而言典型的是master分支)来跟踪你的Debian软件包。对于后者，用场会将未应用补丁的上游源码和你的debian/*文件放在一起以便容易合并上游的新代码。

    创建完包以后，这里的源码正常来说都是已经被打了补丁的了。在你把源码提交到master分支之前，你必须手动的调用dquilt pop -a命令来去掉已经打上了的补丁。你可以在这个可选的文件debian/source/local-options中写入unapply-patches，让它自动完成去除补丁的操作。这个文件的作用只会改变打二进制包，而不会影响到打源码包。这个文件可能也应该包含abort-on-upstream-changes(详情情况dpkg-source(1))。

unapply-patches
abort-on-upstream-changes

5.25.source/options

    在打包的时候，在源码树上会自动生成一些很大的，但是没有用的补丁文件。你可以通过自定义一些模块(例如dh_autoreconf)的行为来解决这个问题。

    你可以提供给命令dpkg-source的选项--extend-diff-ignore提供一个Perl正则表达式作为参数，就可以忽略那些在创建源码包时候自动创建的文件了。

   解决自动生成文件这个问题，通过的做法就是在源码包中增加source/options文件，里面例如命令dpkg-source的参数。下面的展示的就是忽略config.sbu, config.guess和Makefile，不为这三个文件做补丁文件。

extend-diff-ignore= "(^|/)
(config\.sub | config\.guess | Makefile)$"

5.26.patches

在1.0版本，在debian目录中有一个很大的，包含了包的维护文件文件的压缩包diff.gz，它会被用于被源码包打补丁。这样的方法既不方便理解，也不方便使用。

在最新的3.0 (quilt)源码格式中，debian/patches/*目录中存放着用于被quilt调用的补丁文件。这些补丁文件和其他数据文件都被包含在debian目录下，都会被打包成一个debian.tar.gz的文件。自从dpkg-source命令可以处理quilt格式的补丁后，在build-Depends中就可以不用加入quilt这个依赖了。

quilt命令的使用可以参考quilt(1)。它会在deibna/patches目录下，以堆的方式用-p1补丁文件的格式记录源码的修改。而且在debian目录外的源码树不会受到任何影响。补丁的顺序记录在deiban/patces/series文件中。你可以很容易apply(=push), un-apply(=pop),或者更新补丁。

Chapter 6. Building the package

我们现在已经准备好了去编译一个新的包了

6.1.完整的（重）编译

    为了可以完整的编译一个新的包，你要确保你已经安装了：

•     build-essential包
•     control文件中Build-Depends中所指定的包
•     control文件中Build-Depends-indep中所指定的包

    确保了满足上面的东西之后，你可以在源码的目录下执行以下的命令来打包：

dpkg-buildpackage

•     它会做所有执行以下的操作并且为你生成二进制包和源码包。
•     清理源码（debian/rules clean)
•     建立源码包（dpkg-source -b）
•     编译程序（debian/rules build）
•     编译二进制包（fakeroot deiban/rules binary）
•     用gpg签署.dsc文件
•     使用dpkg-genchanges和gpg生成并签署上传用的.change文件

在打包的过程中唯一需要输入的就是GPG密钥。如果你创建的包只是为了给你自己用的话，你可以用下面的命令跳过GPG在.dsc和.changes文件里面的GPG签名

dpkg-buildpackage -us -uc

对于一个非原生的包，例如gentoo，你会在父目录下看到下列的文件：

• gentoo_0.9.12.orig.tar.gz

    这是官方的源码。只是根据debian的标准来重命名了。这是又dh_make -f ../gentoo-0.9.12.tar.gz生成的。

• gentoo_0.9.12-1.dsc

    这是一个从control文件生成的源代码概要，可用于dpkg-source(1)程序。这个文件是使用GPG签署过的，以便别人可以确信它确实是你提供的。

• gentoo_0.9.12-1.debian.tar.gz

    这个压缩包包含了debian文件夹，每一样新增到源码的东西都会被作为一个quilt的补丁保存在debian/patches中。

    如果某人希望重新生成你的软件包，他们可以很容易地利用上面的三个文件来生成。过程很简单：只要三个文件复制到别处，并运行dpkg-source -x gentoo_0.9.12-1.dsc.

• gentoo_0.9.12-1_i386.deb

    这是完整的二进制文件包，你可以用dpkg命令去安装它。

• gentoo_0.9.12-1_i386.changes

    这个文件记录了当前修订版所有的修改。它是被Debian FTP archive maintenance 程序用于安装二进制包和源码包。这个文件有一部分内容是从changelog和.dsc文件中生成的。 这个文件是使用GPG签署的，以便别人可以确信它是你提供的。

    如果你继续维护这个包的话，新增加的功能或者修改够应该增加到这个文件中来。用于下载了你的包，通过这个文件就可以很快的看清楚有什么新增和改变了。

    

    在.dsc和.changes文件中的长数字是SHA1/SHA256的校验码。任何一个人下载你的包，他们都可以用sha1sum或者sha256sum来校验一下，如果是两个校验码不相同，则损坏或已被篡改。

对于一个自己做的包，例如Mypackage，你会在编译完成后在父母路看到一下的包：

• mypackage_1.0.tar.gz

    由dpkg-source生成的源码包。（它的后缀不是orig.tar.gz）

• mypackage_1.0.dsc

    这是源码内容的摘要。（这里没有Debian的修订号）

• mypackage_1.0_i386.deb

    这是完整编译后的二进制安装包（这里没有Debian的修订号）

• mypackage_1.0_i386.changes

    这个文件记录了当前修订版所有的修改。

6.2.Autobuilder

    Debian在很多不同架构的计算机通过运行buildd守护进程来提供很多包含autobuilder netword功能的端口。即使你不需要你自己来做这些，但是你应该清楚它会对你的包做了什么操作。下面我们大概的看看他是怎么给多种架构重建你的包的。

    对于 Architecture: any 的包，你应该保证用于重新打包的系统有安装以下的程序：

•     build-essential安装包
•     在Build-Depends中列出的包

    然后你可以在源代码目录里以下命令：

dpkg-buildpackage -B

它会自动编译出依赖依赖框架的二进制包，它主要做的是：

•     清理源码树 （debian/rules clean）
•     构建程序 （debian/rules build)
•     构建平台依赖的二进制包 （fakeroot debian/rules binary-arch）
•     用gpg编译源文件.dsc
•     使用dpkg-genchanges和gpg生成和上传.change文件

    这就是为什么你的软件包在其他平台上可用的原因了。

    虽然当平常我们打包的时候是需要安装Build-Depends-Indep里所指定的软件，但是在autobuilder里面是不会要求去安装的，因为它只会构建基于架构的二进制包。正常打包与autobuilding之间的区别就是要你应该在debian/control文件中的Build-Depends和Build-Depends-Indep记录下那些依赖的包

6.3.debuild命令

    你以后可以通过debuild命令来自动调用dpkg-buildpackage命令来打包。

    你可以在debuild的配置文件/etc/devscripts.conf或者~/.devscripts文件中自定义debuild行为，推荐至少应该包含以下的条目：

DEBSIGN_KEYID=Your_GPG_keyID
DEBUILD_LINTIAN_OPTS=-i -I --show-overrides

    有了这些，安装包就会被用你的GPG Key ID签名，并且会用lintian命令去检查它的细节。

    清理源码并且重新生成一个包是很简单的，你只要执行

$ debuild

    如果你的包只是给自己用，你可以跳过.dsc文件中的和.changes文件的签名，命令如下：

$ debuild -us -uc

    你可以诶用一下命令清理源码树：

$ debuild clean

6.4.pbuilder package

    要在一个干净的环境(chroot)去验证包的依赖，pbuilder是非常有用的。

6.5.git-buildpackage 命令以及相近的命令

6.6.快速重建

    当需要构建一个很大的包的时候，当你只是调整debian/rules文件后，你肯定不想从头开始编译。出于测试的目的，你可以不重新编译源码而生成一个.deb包：

$ fakeroot debian/rules binary

    或者运行一下的命令看它是否执行
    

$ fakeroot debian/rules build

    一旦完成了调试，记住按照前面说的正常过程重新构建你的软件包。你可坑无法正常上传此种方法构建的.deb包。

Chapter 7. 检查软件包中的错误 

    在你包软件包上传到公开的仓库之前，你必须要先测试这个软件包会不会有错。这里会介绍一些技术用来检查软件包是否有错。

    一个很好的方法就是不是打包的机器上安装这个包。你必须密切关注任何的警告或者错误输出。

7.1 可疑的修改

    如果你创建完一个非本地的软件包后，在debian/patches目录中发现一个类似debian-changes-*这样的自动生成的补丁文件，可能是你不小心改变上游软件的了一些文件或者构建的脚本修改了文件。如果是你的错误，就把问题解决掉。如果是构建脚本导致的，通过定制rules文件或者source/options文件来解决根本的问题。

7.2 验证包的安装

    你必须测试你的包能够正常安装。 debi命令可以帮助你去测试安装所有生成的二进制包。

sudo debi gentoo_0.9.12-1_i386.changes

    避免在不同的操作系统中安装会有问题，你从Debian的仓库下载Contents-i386，来保证的捏包与现有的安装包没有文件名的冲突。apt-file命令可以很方便的完成这个任务。如果真的有冲突，就需要才去行动去避免真正的问题。重命名文件，把文件移动到一个被多个包依赖的包中， 与其他软件包的维护者协调，或者在debian/control长度Confilcts字段中进行说明。

7.3 验证包的维护脚本

    所有的维护脚本(preinst, prerm, postinst和postrm) 很难是完全正确的，除非他们是通过debhelper来生成的。如果你是一个新手的话，就不要使用它们了。

    如果一个包需要使用这些不是很重要的维护脚本，不仅仅需要测试install，还需要测试remove,purge和升级。在删除或者完全删除的时候，很多维护脚本都会在这个时候有bug出现。使用dpkg命令去测试他们。

sudo dpkg -r gentoo
sudo dpkg -P gentoo
sudo dpkg -i gentoo_version-revision_i386.deb

    整个测试过程应该按照以下序列：

• 如果可能，安装前一个版本的软件包
• 从前一个版本升级软件包
• 降级到前一个版本
• 彻底删除该软件包
• 全新安装该软件包
• 卸载该软件包
• 再次安装该软件包
• 彻底删除该软件包

    如果这是你的第一个软件包，你应该使用其他版本号创建一个测试用的软件包进行升级测试，这样可以避免将来的问题。

    请牢记如果你的软件包已经在以往的Debian中发布，人们通常会将从最近发布的Debian发布的版本升级，所以也要测试从那个版本升级到最新的版本。

    虽然降级不是官方所要求支持的，但是支持的话会比较友好。

7.4 调用lintian

    使用lintian(1)来检查你的.changes文件。lintian命令会运行很多测试脚本来检查常见的打包错误。

lintian -i -I --show-overrides gentoo_0.9.12-1_i386.changes

    当然，需要把文件名替换成你生成的.change文件。lintian命令的输出会使用下面的标示符号：

• E : 错误; 肯定违法策略或者安装包有错
• W: 警告; 可能违反策略或者安装包有错
• I :  提示信息，输出安装包某方面的信息
• N : 代表注释，帮助你调试的详细信息
• O : 代表已覆盖：一个被lintian-overrides文件覆盖的信息，但由于使用--show-override选项而显示

    当你看到有警告输出，应该修改安装包避免下次还会有提示，或查证一下这些错误输出是否正确。如否是误报的话，使用lintian-overrides文件去解决它。

7.5 debc命令

    你可以通过debc命令来列出二进制的debian包中的文件

debc package.changes

7.6 debdiff命令

    你可以使用debdiff(1)命令比较两个Debian源代码包的内容

debdiff old-package.dsc new-package.dsc

    你还可以使用debdiff(1)命令比较两个Debian二进制包的文件列表

debdiff old-package.changes new-package.changes

这对于确定在源码包中修改了什么或者在升级时无意中的修改是非常有用的。

7.7 interdiff命令

    你可以使用interdiff(1)命令比较两个diff.gz文件。这对已更新使用旧的1.0源代码格式的软件包时，检查是否有意外的变更非常有用。

interdiff -z old-package.diff.gz new-package.diff.gz

     3.0格式的源码会在patches/*目录中把修改保存成多个patch文件。你也可以使用interdiff去查看每一个patch文件来跟踪源码的变化。

7.8 mc命令

    很多文件检查操作可以通过类似mc(1)的文件管理器来完成，它可以帮助你直接查看*.deb文件的内容，除此之外还可以用于*.udeb, *.debian.tar.gz, *.diff.gz和*.orig.tar.gz文件。

    在你的二进制包和源码包中，查找出那些不需要的文件或者长度为0的文件。通常这些文件都是不会被清理掉的，所以你就要通过定义rules文件来解决这个问题。

Chapter 8. Updating the package

当你发布了一个软件包，你需要尽快的更新它。

8.1 新的debian的版本

如果有一个bug的报告是针对你的包的，而且这个报告中已经描述了是怎么一个问题，你就需要去解决这个问题了。这里介绍了需要怎么去做一个新的修正版的包。

• 如果需要将它记录到新的补丁中，这样做：

1. dquilt new bugname.patch设置补丁的名字
2. dquilt add bugg-file说明修改了哪些文件
3. 修正软件包代码中的上游bug
4. 把dquilt refresh的输出记录到bugname.patch中
5. dquilt header -e把它添加到描述

• 如果是更新一个已存在的补丁，这样做：

1. dquilt pop foo.patch 重新调用foo.patch
2. 修正旧的foo.patch中的问题
3. dquilt refresh去更新foo.patch
4. dquilt header -e去更新它的描述
5. while dquilt push; do dquilt refresh; done; 在删除fuzz的时候适用请求调用所有补丁。

• 在Debian changelong文件的顶部添加一个条目。例如可以适用dch -i或者dch -v version-revision来指定版本，然后用你喜欢的编译器插入信息
• 在changlog的条目， 在Closes: $654321后加入一个关于这个bug的简短描述和解决情况。这样做的话，当你的包被合并到debian的仓库的时候，bug的报告将会被自动关闭。
• 重复上述操作来修复更多的Bug，并在需要的时候用dch更新Deiban changelog文件。
• 重新构建你的包(6.1节)和检查包的错误(第7章)
• 一旦你对你的包已经比较满意了，你应该把changelog中distribution的值由UNRELEASED改为unstable或者experimental。
• 上传你的包。

这里会遇到一个棘手的问题，在你把一个包改成experiment之前你已经上传了一个包到官方的的仓库，版本是1.0.1-1。为了可以平滑的升级上去，一个好的建议就是在changelog里面增加一个包含版本信息未1.0.1-1~rc的条目。你应该把本地多条的changelog条目整理到一条，然后再加入到官方的包中。

8.2 检查新上游版本

    当你打算为Debian仓库打一个上游软件的新的发行版时，你必须首先检查新的发行版。

    首先阅读一下上游软件的changelog， NEWS和其他有关该新发行版文档

    然后你可以查看两个版本之间的差别，看看有没有什么是可疑的。

diff  -urN foo-oldversion foo-newversion

在missing, aclocal.m4, config.guess, config.h.in, config.sub. configure, depcomp, install-sh, ltmain.sh和Makefile.in这些可以忽略，你可以在比较之前就把这些文件给删掉。

8.3 新上游版本

    

8.4 更新打包风格

Chapter 9. Uploading the package