trunk/maint-guide/maint-guide.zh_CN.sgml

<!DOCTYPE debiandoc PUBLIC "-//DebianDoc//DTD DebianDoc//EN" [

        <!-- textual data entities -->
        <!-- first definition wins in SGML -->
<!ENTITY % default  SYSTEM "default.ent">  %default;

]>
<!-- CVS revision of this document "$Revision: 1.6 $"  -->
<!-- CVS revision of original english document "*.**"  -->


<debiandoc>

 <book>

  <titlepag>

   <title>Debian新维护人员手册</title>

   <author>Josip Rodin <email/joy-mg@debian.org/
   </author>
<!--
   <author>中文版翻译：[李凌] <email/[lilingv@hotmail.com]/
   </author>
  -->

   <version>version 1.2, 2002年4月6日.</version>

   <copyright>
   <copyrightsummary>版权所有 &copy; 1998-2002 Josip Rodin.</copyrightsummary>

   <p>本文档可以在GNU通用公众授权的第2或更高的版本下使用。

   <p>This document was made using with these two documents as examples:

   <p>Making a Debian Package (AKA the Debmake Manual), copyright &copy;
   1997 Jaldhar Vyas.

   <p>The New-Maintainer's Debian Packaging Howto, copyright &copy; 1997
   Will Lowe.
   </copyright>

  </titlepag>

  <toc sect>

  <chapt id="start">从一条正确的路开始

  <p>这篇文章为普通的Debian用户和希望能够对Debian安装包有所了结的开发人员讲述
     了制作Debian安装包的方法。它使用了非常通用的语言，并且通过一个可以工作的
     例子进行了演示。有一句古老的罗马谚语说的好：<em>Longum iter est per 
     preaecepta, breve et efficax per exempla!</em>
     (通过理论要讲述很久的问题，可以很快地用例子说明白。)

  <p>Debian能够成为一个高质量的Linux发行版的重要原因之一就是它的安装包系统。
     尽管已经存在相当大量的用Debian格式打包的软件，有时你还是需要安装一些不是
     这一格式的软件。可能你会为如何制作自己的安装包而彷徨，而且也许你会认为这
     是一个非常困难的任务。是的，如果你是一个Linux初学者，那么这的确很难，不过
     如果你真的是一个新手，现在你也就不会来读这个文档了。:-) 你的确需要对Unix
     的编程有所了解，但你并不需要是这方面的天才。

  <p>有一件事情是非常明确的：如果你希望创建并维护一个Debian的安装包，那将花费
     你数个小时的时间。为了能够没有错误，让我们的系统很好地工作，作为一个维护
     人员，必须有技术上的基础并且非常勤奋。

  <p>这篇文档将会讲述每一个细小(开始时也许给人感觉毫不相干)的步骤，并且帮助你
     创建第一个安装包，从而让你学习到可以帮助你制作它的下一个版本或者其它安装
     包的经验。

  <p>这个文档的更新版本可以在 <url name="http://www.debian.org/doc/maint-guide/" id="http://www.debian.org/doc/maint-guide/">
     和 `<package/maint-guide/' 安装包中找到。这个文档的中文翻译版本也可以在
     `<package/maint-guide-xy/' 安装包中找到。

  <sect id="needprogs">开发时需要的软件

  <p>在开始之前，你需要确认你是否已经正确安装了一些附加的在开发时需要的安装包。
     注意这里列出的软件都没有标记为`essential'或者是`required'——我们希望你能
     够安装好这些软件。

  <p>这个文档的当前版本已经为Debian 2.2(`potato')和3.0(`Woody')更新过了。

  <p>下面列出的这些软件在Debian的标准安装中已经有了，因次它们在你的机器上应当
     已经安装好了(也包括它们倚赖的其它软件包)。然而，你还是应该用
     `dpkg -s &lt;package&gt;`来检查一下。

  <list>
  <item>
     <package/dpkg-dev/ - 这个软件包包括了在解包、制作、上传Debian源文件包时需要用到的
     工具。
     (参考<manref name="dpkg-source" section="1">)

  <item>
     <package/file/ - 这个小程序可以检测文件的类型。
     (参考 <manref name="file" section="1">)

  <item>
     <package/gcc/ - GNU C语言编译器，如果你的程序是和其它很多程序一样用C
     语言编写，那么就需要这个软件包。(参考 <manref name="gcc" section="1">)
     这个软件包还会"pull in"其它几个软件包，比如包括汇编和链接目标文件的程序的软件包
     <package/binutils/(参考<package/binutils-doc/软件包中的`info binutils`)和C预处理
     器<package/cpp/(参考<manref name="cpp" section="1">)。

  <item>
     <package/g++/ - GNU C++语言编译器，如果你的程序是用C++语言写的那就需
     要它。
     (参考 <manref name="g++" section="1">)

  <item>
     <package/libc6-dev/ - gcc需要的用于链接和创建目标文件的C函数库和头文件。
     (参考 <package/glibc-doc/ 软件包中的 `info libc`)
  

  <item>
     <package/make/ - 通常创建一个程序的过程需要经过好几步，为了能够不把同样的
     命令一遍又一遍的输入，你可以用这个程序通过创建`Makefile'来使这个
     过程自化。
     (参考 `info make`)

  <item>
     <package/patch/ - 这是一个非常有用的工具，它可以把(用diff程序生成的)包含
     有一个差别列表的文件应用到原先的文件上去，从而生成一个补丁版本的
     程序。
     (参考 <manref name="patch" section="1">)

  <item>
     <package/perl/ - Perl是在当今的Unix类系统上应用得非常广泛的解释型脚本语
     言之一，它通常被称作“Unix的瑞士军刀”。
     (参考 <manref name="perl" section="1">)
  </list>

  <p>你也很可能会想要安装下面的软件包：

  <list>
  <item>
     <package/autoconf/和<package/automake/ - 很多新的程序在这一类工具的帮助下来配制
     脚本文件并对Makefiles进行预处理。
  (参考 `info autoconf`， `info automake`)

  <item>
     <package/dh-make/和<package/debhelper/ - 在例子中创建我们的软件包时需要使用
     dh-make来创建它的骨架，并且要使用到一些debhelper软件包中的工具。
     他们对于创建软件包不是最基本的，但对于新的维护者则是<strong>强烈</strong>推荐使
     用的。它们使得整个过程的开始变得很容易且使后续的过程容易控制。
     (参考<manref name="dh_make" section="1">，<manref name="debhelper" section="1">，/usr/share/doc/debhelper/README)

  <item>
     <package/devscripts/ - 这个软件包中包括了一些非常好的且很有用的脚本程序，
     它们对于维护者是很有用的，但它们对创建软件包也不是必需的。
     (参考 /usr/share/doc/devscripts/README.gz)

  <item>
     <package/fakeroot/ - 这个工具使你可以模拟变成root用户，这在创建软件包的过
     程的一些部分是必要的。
     (参考 <manref name="fakeroot" section="1">)

  <item>
     <package/gnupg/ - 一个可以让你对你制作的软件包进行数字<em>签名</em>的工具。
     如果你希望把它发布给其他人，这个步骤是非常重要的，并且当你所做的
     工作被加入到Debian发行版中时就必需进行这一步。
     (参考 <manref name="gpg" section="1">)

  <item>
     <package/g77/ - GNU Fortran 77语言编译器，如果你的程序是用Fortran语言编写
     的就需要它了。
     (参考 <manref name="g77" section="1">)

  <item>
     <package/gpc/ - GNU Pascal语言编译器，如果你的程序是用Pascal语言写的，
     就需要它了。这里值得一提的是软件包<package/fp-compiler/，自由Pascal编译
     器(the Free Pascal Compiler)，它也是一个完成这一任务的好选择。
     (参考 <manref name="gpc" section="1">， <manref name="ppc386" section="1">)

  <item>
     <package/xutils/ - 一些程序，通常是为X11编写的程序，也使
     用这些程序通过一套宏来生成Makefile文件。
     (参考 <manref name="imake" section="1">，<manref name="xmkmf" section="1">)

  <item>
     <package/lintian/ - 这是一个Debian软件包检查程序，它可以在你创建软件包
     后为你找出一些常见的错误，并解释这些错误。
     (参考 <manref name="lintian" section="1">，/share/doc/lintian/lintian.html/index.html)
  </list>

  <p>下面列出的这些文档都<em>非常重要</em>，你在阅读本文档时也应当阅读它们：

  <list>
  <item>
     <package/debian-policy/ - 政策(Policy)文件中包含了对很多内容的解释，比
     如Debian档案的结构及内容、几个关于操作系统设计的问题、文件系统
     层次标准(讲述了每个文件和目录应该存在的地方)等等。
     对你来说，最重要的是它描述了在被加入到发行版中时每个软件包必须
     满足的要求。
     (参考 /usr/share/doc/debian-policy/policy.html/index.html)

  <item>
     <package/developers-reference/ - 包含了全部的参考资料，其内容不只是打
     包软件的技术细节，比如文档的结果、如何该名、孤儿、选择软件包、
     如何做nmus、如何管理bugs以及在什么时间将软件包上传到什么位置等
     等。
     (参考 /usr/share/doc/developers-reference/developers-reference.html/index.html)
  </list>

  <p>上面的简短描述只是对每一个软件包进行了一下简单的介绍。在几许后面的工作
     前，请完整的阅读每一个程序的文档，至少要了解基本的用法。现在看来也许是
     很繁重的任务，不过以后你会非常<em>高兴</em>的去阅读它们的。

  <p>注意: <package/debmake/软件包中包含了一些和dh-make作用相似的程序，但它的详
     细用法并没有包含在这份文档中，因为它已经<em>不推荐</em>使用了。要得到更多的
     信息，请参考
     <url name="the Debmake manual" id="http://www.debian.org/~jaldhar/">。

  <sect id="otherinfo">其它信息

  <p>你可以制作的软件包有两种，源文件版本和可执行版本。源文件版本的软件包包
     含了可以被编译成程序的源代码。可执行版本的软件包只包含编译好的文件。不
     要把程序源文件和程序的源文件版本软件包混在一起！如果你需要更详细的关于
     这些词汇的资料，请参考阅读其它的手册。

  <p>在Debian中，`维护者(maintainer)'一词指的是制作软件包的人，`上游作者
     (upstream author)'指的是编写程序的人，而`上游维护者(upstream 
     maintainer')是指在Debian项目之外维护着程序的人。通常情况下作者和上游维
     护者是同一个人——有时维护者甚至也是同一个人。如果你编写了一个程序并且
     希望它被包含到Debian中，那么你可以提交你的程序从而成为一个维护者。

  <p>在你创建了你的软件包(或则正在做这件事情)，若你希望它能够被加入到下一个
     发行版中(如果你的程序非常有用，为什么不呢？)，那么你必须成为一个正式的
     Debian维护者。这一过程在开发人员参考(Developer's Reference)中解释了。
     请阅读它。

  <chapt id="first">第一步

  <sect id="choose">选择你的程序

  <p>你大概已经选好了你要制作的软件包。首先要做的事情是检查它是否已经在发行
     版中了。如果你使用的是`稳定'发行版，那么你最好到<url name="软件包查询
     页面" id="http://www.debian.org/distrib/packages">查一下。如果你使用的
     是<strong>当前的</strong>`不稳定'发行版，可以用下面的命令来检查：
  <example>
  dpkg -s program
  dpkg -l '*program*'
  </example>

  <p>如果软件包已经存在了，那么好，安装它！ :-) 如果他碰巧是个孤儿——如果
     它的维护者成为了"Debian QA Group"的成员，你就应该可以重新维护它。查询
     <url name="孤儿软件包列表" id="http://www.debian.org/devel/wnpp/orphaned">和<url name="打算收养的软件包列表" id="http://www.debian.org/devel/wnpp/rfa_bypackage">
     可以确认软件包是否真的需要领养。

  <p>如果你获准收养一个软件包，那就获取它们的源代码(用
     <tt/apt-get source packagename/一类的命令)并检查它们。很不幸，这份文档中
     并不包含关于收养软件包的详细信息。值得庆幸的是，当收养软件包时，你不
     用花费很多时间在找出如何让其公主，因为已经有人为你做了初始的设置工
     作。尽管如此，也请继续读下去，下面的很多建议也会对你所处的情况有用。

  <p>如果软件包是新的，并且你已经决定让它出现在Debian中，请按照下面的步骤来做：

  <list>
  <item>到<url name="正在制作中的软件包列表" id="http://www.de.debian.org/devel/wnpp/being_packaged">
  检查是否没有其它人正在为打包同一个软件而工作。
  如果已经有人正在做了，并且你觉得它对你很重要，就请和他们取得联系。
  否则——找另一个没人维护的有趣程序吧。
  </item>

  <item>每一个软件都<strong>必需</strong>有授权，如果有可能最好是象<url name="Debian自由软件指导方针" id="http://www.debian.org/social_contract#guidelines">
  中说的那样属于自由软件。如果它并不遵守这些规则但仍然可以以任意形式
  发布，它也还可以被加入到`contrib'或者`non-free'部分中。如果你不确
  定它究竟应该被放到哪里，可以把它的授权文字发到
  <email/debian-legal@lists.debian.org/问一下该怎么做。
  </item>

  <item>程序的确<strong>不</strong>应当以setuid root的方式运行，或者最好
  它应该不需要setuid或setgid成为其它任何东西。
  </item>

  <item>程序不能是一个守护程序，且它不应该放到*/sbin目录中去，也不该以
  root身份打开一个端口。
  </item>

  <item>程序最终应当是二进制可执行的形式，库处理起来要困难一些。</item>

  <item>它应当有很好的文档，或者连源代码也应该是可以被理解的(比如不能很
  混乱)。</item>

  <item>你应该与程序的作者取得联系问一下他是否同意程序被打包。能够向作
  者咨询关于程序的任何问题是非常重要的，不要试着去打包一个没有人
  维护的软件。</item>

  <item>最后的但并不是不重要的，你必需知道它确实可以工作并且已经试着使
  用了一段时间。</item>
  </list>

  <p>当然，这些问题都是只是为了安全，并试着让你不至于在比如setuid的守护进
  程等问题上犯错误而激怒了用户。当你有了在打包软件方面的更多经验时，你就可
  以处理那种软件包了，但即便是富有经验的开发人员在他们疑惑时也会发邮件到
  debian-mentors邮件列表咨询。那里的人们会很乐意提供帮助的。

  <p>要获得关于这些内容的更多帮助，请参考开发者参考手册。

  <sect id="getit">获得程序，并且试用它

  <p>第一件要做的事情就事找到并下载原始的软件包。我假定你已经从作者的主页
  上找到它的源文件了。免费的Unix程序的源文件通常是以tar/gzip格式提供的，它
  的文件扩展名是 .tar.gz，并且通常还包含了以program-version形式命名的子目
  录，里面放着全部的源文件。如果你的程序源文件是以一些其它的形式提供的(比
  如，文件名是以".Z"或".zip"结尾的)，那么就用适当的工具把它解包，或者如果你
  不清楚应当如何正确把它解包，就在debian-mentors邮件列表上问一下。
  (提示：可以用命令`file archive.extension`)

  <p>作为一个例子，我将会使用程序`gentoo'，它是一个基于X GTK+的文件管理器。
  需要注意的是，这个程序已经被打包好了，并且从写这篇文档之初到现在它已经发
  生了很大的变化。

  <p>在你的home目录中创建一个名为'debian'或者'deb'或者任何你喜欢的名字的目
  录(比如在这个例子中~/gentoo/就可以了)。把下载的文件放到这个目录中，然后
  将其解包(用命令`tar xzf gentoo-0.9.12.tar.gz`)。确认在这个过程中没有发
  生错误，即便是一些不"平滑"的也不行，因为当在别人的系统上解包这些文件的
  时候，如果它们的工具并不忽略这些反常的现象，那就会有了。

  <p>现在又有了一个新的子目录，名叫'gentoo-0.9.12'。进入这个目录并且<strong>彻底</strong>
  的读完其中的文档。通常情况下在目录里面会有名叫 README*、INSTALL*、
  *.lsm或者*.html的文件。你必需找到如何正确编译并安装程序的指导。(最有可
  能的是它们会假设你希望把程序安装到/usr/local/bin目录中；你你不需要这样
  做，但在后面的<ref id="destdir">中需要着很多事情。)

  <p>安装的过程对于不同的软件是不同的，但很多现代的程序都带有一个
  `configure'脚本文件，这个文件配制你系统上的源文件，并确认你的系统已经
  可以编译它了。在通国`./configure'命令配制之后，通常可以通国`make`来编
  译程序。有一些程序还会支持通过`make check`命令来进行自检。把程序安装到
  目标目录中的命令通常是`make install`。

  <p>现在可以试着编译并运行你的程序了，从而确定它可以很好的工作并且在它
  安装或工作时不会破坏其它程序的运行。
  
  <p>另外，通常你还可以通过`make clean`(或者更好的`make distclean`)命令
  来清理build目录。有时还会有一个`make uninstall`命令来删除所有已经安装
  的文件。

  <sect id="namever">软件包名称和版本

  <p>在开始打包时，源程序目录应当是绝对干净的，或者直接从刚刚解包的源代
  码目录开始。
  
  <p>为了让软件包能够正确地制作，你必须把程序原有的名字改成小写(如果它不
  是的话)，并且你应该把源代码目录的名字改成&lt;packagename&gt;-&lt;version&gt;
  的形式。
  
  <p>如果程序的名字是由多于一个的英文单词组成的，那就把它改成一个单词，
  或者缩写的形式。例如，程序"John's little editor for X"软件包可以改成
  johnledx或者jle4x，或者随便什么你认为合适的，只要它符合一些很合理的限
  制，比如在20个字符以内。

  <p>另外要做的一件事情就是检查一下被包装在软件包里的程序的精确版本号(它
  将被包含在软件包的版本号中)。如果包装的软件并不是以X.Y.Z的方式来命名它
  的版本的，而是用比如日期一类的方式，那么就用那个日期来做版本号好了，只
  要在前面加上"0.0."就可以了(直到上游的人决定发布一个好的版本比如1.0等时
  候)。因此，如果发行版或者snapshot的日期是1998年12月19日，你就可以使用
  0.0.19981219作为版本号。

  <p>有一些程序根本就没有数字的版本，在这种情况下，你就需要和上游维护者
  取得联系，看看他们是不是使用了什么别的版本跟踪方法。

  <sect id="dh_make">Debian初始化(Initial "debianization")

  <p>确定你在程序的原代码目录中，然后执行这个命令：

  <p><example>
  dh_make -e your.maintainer@address -f ../gentoo-0.9.12.tar.gz
  </example>

  <p>当然，要用你的e-mail地址换掉字符串"your.maintainer@address"，并用你
  的源代码文档的名字替换掉上面的文件名。你的这个e-mail地址将会被包含在
  changlog项目和其它的文件中。参考<manref name="dh_make" section="1">获得详细的信息。
 
  <p>在执行这个命令后，你将会看到一些信息，它会问你你需要创建那种类型的
  软件包。Gentoo是一个单二进制软件包——它只创建一个二进制形式的软件包，
  也就是说只有一个.deb文件——所以我们按`s'键选择第一个选项，检查屏幕上
  的信息，然后按&lt;enter&gt;键确认。

  <p>再说一下，作为一个新的维护者，创建多个二进制格式软件包或者库都是不
  被鼓励的。其实这并不是很难，但它确实需要更多一些的知识，所以我们不会在
  这里讲述关于它们的全部内容。

  <p>请注意你只能运行<strong>一次</strong>dh_make程序，如果你再次在同一个已经
  "Debian化"的目录中运行它，它将不能正常运行。这也意味着当你要发布你的软
  件的下一个版本时，你需要使用一些不同的方法。以后你会在
  <ref id="update">一部分中读到更多关于这个问题的内容。

  <chapt id="modify">修改源代码

  <p>通常情况下，程序会把它们自己安装到/usr/local子目录中。但是Debian的
  软件包绝对不能使用那个目录，因为它被保留给系统管理员(或者用户)使用。这
  就是说你必需要仔细看一下你的程序的构造系统，通常从Makefile开始。它是
  <manref name="make" section="1">将会使用的用于自动构造程序的脚本。要了
  解更多关于Makefiles的内容，请参考<ref id="rules">。

  <p>注意如果你的程序使用了GNU的<manref name="automake" section="1">和/或
  <manref name="autoconf" section="1">，也就意味着源代码是在Makefile.am
  和/或Makefile.in文件中，相应的，你需要修改这些文件。这是因为在每一次
  automake的调用中，Makefile.in等文件中的信息将会通国Makefile.am等文件来
  重新产生，并且每次调用./configure时，类似的操作会执行在Makefile等文件
  上，它们会被根据Makefile.in文件重新产生。修改Makefile.am文件需要一些关
  于automake的知识，你可以阅读automake的info项目，然而修改Makefile.in文件
  和修改Makfile文件是差不多的，不过要注意一下变量，例如，任何被`@'包围的
  字符串如@CFLAGS@或@LN_S@将会在每次./configure调用时被用实际的值替换掉。

  <p>还需要注意的是，在这里我们没有地方讨论所有的修改上游源代码的细节，
  这里我们只有一些人们经常会会遇到的问题。

  <sect id="destdir">在一个子目录中安装

  <p>大多数的程序都能够以某种方式把自己安装到你的系统现有的目录结构上，
  所以它们的可执行文件已经存在于你的$PATH中，并且你也可以在通常的位置找
  到它们的文档和手册。然而，如果你这样做，这些程序将会被和你系统上的其它
  程序安装在一起。这样的话，对于打包工具而言要想把它们同不属于这个软件包
  的程序区分开来将是一件很困难的事情了。

  <p>因此，你还必须要做一些其它的事情：把程序安装到一个临时的子目录中，
  从这里打包工具可以创建一个可以工作的.deb软件包。在这个目录中的所有内容
  都将会被安装到用户的系统中，当他们安装你的软件包时，唯一的不同是dpkg将
  会把这些文件安装到文件系统的跟目录上。

  <p>这个临时文件目录通常创建在源代码目录的debian/子目录中。通常情况下，
  它的名字是<file>debian/tmp</file>或者<file>debian/packagename</file>。

  <p>有一件事情请记住，尽管你要把程序安装到debian/packagename目录中，当
  它需要被安装到根目录中时仍然应该是正常的，比如在安装.deb文件的时候。所
  以你绝对不能让软件包的构造系统把类似于
  <tt>/home/me/deb/gentoo-0.9.12/usr/share/gentoo</tt>的字符串写入到软件包
  中。

  <p>对于使用GNU autoconf的程序而言，这个工作是非常简单的。大多数这样的
  程序的makefile脚本缺省状态下就允许程序被安装到任何的子目录中，并以(例
  如)/usr作为它的规范前缀。当检测到你的程序使用了autoconf时，dh_make发现
  将会自动设定命令完成这一任务，因次你可以跳过下面的部分。但对于其它的程
  序，你极有可能不得不检查并修改Makefile文件。

  <p>这里是gentoo的Makefile文件的相应部分：

  <p><example>
  # Where to put binary on 'make install'?
  BIN     = /usr/local/bin

  # Where to put icons on 'make install'?
  ICONS   = /usr/local/share/gentoo
  </example>

  <p>我们发现这个文件被设定成为安装到<file>/usr/local</file>目录下。将这些路
  径改为：

  <p><example>
  # Where to put binary on 'make install'?
  BIN     = $(DESTDIR)/usr/bin

  # Where to put icons on 'make install'?
  ICONS   = $(DESTDIR)/usr/share/gentoo
  </example>

  <p>但为什么要在这个目录中而不是其它的呢？这是因为Debian绝不会把文件安装
  到<file>/usr/local</file>目录中——那个目录是留给系统管理员用的。这些文
  件在Debian系统上都会被安装到<file>/usr</file>目录下。

  <p>在文件系统层次标准中描述了更多的关于二进制、图标、文档等文件放置位置
  的信息(请参考/usr/share/doc/debian-policy/fhs/)。我建议你浏览一下其中可
  能与你的软件包有关的部分。

  <p>因此，我们应该把二进制文件安装在/usr/bin目录中而不是/usr/local/bin目
  录中，把手册安装在/usr/share/man/man1目录中而不是/usr/local/man/man1目
  录中。也许你注意到在gentoo的makefile中并未涉及到手册文件，但Debian政策
  要求每个程序都要有一篇手册，因次我们稍后会制作一份并把它安装到
  /usr/share/man/man1中。

  <p>有一些程序并不像这样使用makefile的变量来定义其路径。这就意味着你不
  得不去修改一些C源程序 来使其能够在正确的位置找到文件。但如何才能找到这
  些代码的位置呢？你可以使用这样的命令：

  <p><example>
  grep -rn usr/local/lib *.[ch]
  </example>

  <p>Grep会递归地搜索整个源代码目录树，并在找到相应的字符串时告诉你它所
  在文件的名字和在文件中所处行的行号。

  <p>修改那些文件，并用usr/*替换掉原来的/usr/local/*以及所有相关的内容。注
  意不要为了修改这些地方而把代码的其它部分搞乱。 :-)

  <p>之后，你应该找到install目标(查找以`install:'开始的行)并修改所有对于
  目录的引用，使其和在Makefile的开始部分定义的一致。最初的时候，gentoo的
  install目标是下面的样子：

  <p><example>
  install:        gentoo
                  install ./gentoo $(BIN)
                  install icons/* $(ICONS)
                  install gentoorc-example $(HOME)/.gentoorc
  </example>

  <p>在我们修改以后它变成了这个样子：
  <example>
  install:        gentoo-target
                  install -d $(BIN) $(ICONS) $(DESTDIR)/etc
                  install ./gentoo $(BIN)
                  install -m644 icons/* $(ICONS)
                  install -m644 gentoorc-example $(DESTDIR)/etc/gentoorc
  </example>

  <p>你一定已经注意到在其它命令之前有一个<tt>install -d</tt>命令。原来的
  makefile脚本没有它是因为通常情况下在运行`make install'时，
  /usr/local/bin和其它的目录都已经存在于文件系统上了。然而，我们是要把文
  件安装到我们的空的(或者是根本不存在的)目录中，因次我们不得不首先创建每
  一个目录。

  <p>在rule文件的结尾，我们还可以加入其它的内容，比如安装上游作者忽略掉
  的附加文档，如下所示：

  <p><example>
                  install -d $(DESTDIR)/usr/share/doc/gentoo/html
                  cp -a docs/* $(DESTDIR)/usr/share/doc/gentoo/html
  </example>

  <p>细心的读者应该已经注意到我把`install:'一行中的`gentoo'改成了
  `gentoo-target'。这被称为无关bug修复 :-)

  <p>当你做了一些并不特定地与Debian软件包相关的修改时，请一定要把它们发
  送给上游的维护者，这样这些修改就可以被包含在软件的下一个版本中，这样会
  对其他人非常有用。还要记住不要使你的修改只是针对Debian或者Linux(甚至是
  Unix！)，在发送它们之前——让它们具有可移植性。这将会使你的修改更容易
  被接受。

  <p>注意，你不需要把debian/*文件也发送给上游的人。

  <sect id="difflibs">不一样的库名称

  <p>有一个非常普遍的问题：在不同的平台上链接库通常是不一样的。例如，
  Makefile中包含了对一个库的引用，但Debian系统上并没有这个库。在这种情况
  下，我们需要把它修改成为一个在Debian中确实存在并且完成相同功能的库。

  <p>因此，如果在你的程序的Makefile(或者Makefile.in)中有类似于下面的一行
  (并且使你的程序无法编译了)：

  <p><example>
  LIBS = -lcurses -lsomething -lsomethingelse
  </example>

  <p>可以把它改成这样，通常情况下它都能工作：
  <p><example>
  LIBS = -lncurses -lsomething -lsomethingelse
  </example>

  <p>(作者已经注意到这并不时最好的例子，因为我们现在使用的libncurses软件
  包在发布的时候包含了一个libcurses.so的符号链接，但他没能想到更好的。欢
  迎你提些建议 :-) 

  <chapt id="dreq">debian/目录中必需的内容

  <p>在程序的源代码目录中有一个名叫`debian'的新子目录。在这个子目录中有
  很多我们需要文件，通过修改这些文件可以定制软件包的行为。其中最为重要的
  是`control'、`changelog'、`copyright'和`rules'，它们对于所有的软件包都
  是必需的。

  <sect id="control">`control'文件

  <p>在这个文件中包含了很多变量，<prgn/dpkg/、<prgn/dselect/和其它软件包
  管理工具通过它们来管理软件包。

  <p>dh_make为我们创建的control文件如下所示：

  <p><example>
  1  Source: gentoo
  2  Section: unknown
  3  Priority: optional
  4  Maintainer: Josip Rodin &lt;joy-mg@debian.org&gt;
  5  Build-Depends: debhelper (>> 3.0.0)
  6  Standards-Version: 3.5.2
  7
  8  Package: gentoo
  9  Architecture: any
  10 Depends: ${shlibs:Depends}
  11 Description: &lt;insert up to 60 chars description&gt;
  12  &lt;insert long description, indented with spaces&gt;
  </example>
  (我为增加了行号。)

  <p>1-6行是源程序形式软件包的控制信息。

  <p>第1行是源程序包的名字。

  <p>第2行是源程序包在发行版中所属部分。

  <p>你也许已经注意到了，Debian被分成许多不同的部分：包括main(自由软件)、
  non-free(非自由软件)和contrib(基于非自由软件的自由软件)。在这些部分中，
  还有子分类，这些子分类以简短的方式说明了软件包的用途。比如`admin'是只有
  系统管理员才能使用的程序，`base'是基本的工具，`devel'是给程序员使用的工
  具，`doc'是文档，`libs'是函数库，`mail'是邮件阅读工具和守护程序，`net'
  是网络应用程序和守护程序，`x11'是不属于以上各个部分的X11程序，还有更多
  这里就不一一叙述了。

  <p>我们把它改成x11。("main/"是缺省的前缀，因次我们可以忽略它。)

  <p>第3行描述了在用户安装系统时此软件包的重要程度。参考政策手册中相应的
  指导可以知道应当把它设置成什么。"optional"的优先级对于新软件包通常是合
  适的。

  <p>所属部分和优先级对<prgn/dselect/等前端软件是有用的，它们在排序和选择
  缺省的软件包时会用到这些变量。当你把软件包上传到Debian以后，这两个字段
  的值可以被文档维护员修改，在这种情况下，你会收到一封通知电邮。
  
  <p>因为这是一个普通级别的软件包，并且它不和其它任何软件包冲突，我们让它
  保留原来的"optional"。

  <p>第四行是维护者的姓名和电子邮件地址。一定要保证这个字段包含有一个合法
  的电子邮件"To: "字段，因为在你把软件包上传以后，bug跟踪系统将会使用这个
  地址来传递通知bug信息的电子邮件给你。不要使用逗号、ampersands和
  parenthesis。

  <p>第五行包括了要构件你的软件包需要的软件包列表。包括gcc和make在内的一
  些软件包是不需要列出来的，关于此内容的详细信息可以参考软件包
  <package/build-essential/。如果在构造你的软件包时需要一些非标准的编译器或者
  是其它的工具，你就需要把它们加到`Build-Depends'这一行上。多个项目之间用
  逗号隔开；要了解关于这个项目的语法的更多信息，请阅读关于二进制文件倚赖
  性的解释。

  <p>你还可以在这里加入Build-Depends-Indep、Build-Conflicts和其它一些字
  段。Debian的软件包自动构造系统将会使用这些数据为其它的计算机平台创建二
  进制软件包。可以参考政策手册中关于build-dependencies的部分和程序员参考
  手册，里面包含有关于其它平台(体系结构)以及如何把软件移植到上面的更多信息。

  <p>要想知道你的软件在编译的时候需要用到哪一个软件包，可以通过下面的方法：
  <example>
  strace -f -o /tmp/log ./configure
  # or make instead of ./configure, if the package don'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
  </example>

  <p>Gentoo还需要软件包<package/xlibs-dev/、<package/libgtk1.2-dev/和
  <package/libglib1.2-dev/才能够构造，因此我们把它们加到<package/debhelper/
  的后面。

  <p>第6行是这个软件包遵循的Debian政策标准的版本，也就是你在制作这个软件
  包时读的政策手册的那个版本。
  
  <p>第8行是二进制软件包的名字。它通常和源文件软件包有一样的名字，但实际
  上并不一定得是这样。

  <p>第9行描述了可以使用这个二进制软件包的CPU类型。我们让它保持原来的
  "any"值，因为<manref name="dpkg-gencontrol" section="1">会在为任何一种
  机器编译这个软件包时自动为这个字段填写合适的值。
  
  <p>如果你的软件包是体系结构无关的(比如一个shell或Perl脚本，或者是文
  档)，就把这个字段修改成"all"，另外在稍后还要仔细看一下<ref id="rules">
  中关于用`binary-indep'规则来代替`binary-arch'规则的内容。

  <p>第10行显示了Debian软件包系统的一个强大功能。软件包可以通过多种不同的
  方式和其它的软件包相关连。除了Depends:之外，还有其它的关联字段，它们是
  Recommends:、Suggests:、Pre-Depends:、Conflicts:、Provides:和Replaces:。

  <p>在管理这些软件包的关联时，所有的软件包管理工具通常的行为都是一样的；
  如果不是这样的话，它将会给出解释。(参考<manref name="dpkg" section="8">、
  <manref name="dselect" section="8">、<manref name="apt" section="8">、
  <manref name="aptitude" section="1">等。)

  <p>下面给出每一种软件包依存性的含义：

  <p><list>
  <item>Depends:
  <p>除非把此软件包所倚赖的所有其它软件包安装好，否则软件包将不会被安
     装。你可以在除非提供了一个其它的软件包，否则你的软件包绝对不能运
     行(或者会导致严重的breakage)时使用这种关联。</item>

  <item>Recommends:
  <p>dselect或者是aptitude等前端工具在安装你的软件包的时候，它们会问
     你是否将与该软件包以推荐的方式相关联的软件包一起安装；dselect甚
     至会坚持这样做。而dpkg和apt-get会忽略这个字段。这个字段可以被用
     于那些并不是严格需要却经常会和你的软件包一起使用的软件包。</item>

  <item>Suggests:
  <p>在一个用户安装你的软件时，所有的前端工具都会询问他是否要安装被建
     议的软件包。dpkg和apt-get不会这样做。这个字段可以被用于那些可以和
     你的程序非常好地一起工作但并不是必需的软件包。
  </item>

  <item>Pre-Depends:
  <p>它的要求比Depends:更强。除非它需要的软件包已经安装<em>并且正确配制</em>
     好，它才会被安装。使用这个标签是<strong>非常</strong>sparingly的，要使用
     它一定要先在debian-devel邮件列表上讨论完才可以。读一遍这句话：
     绝对不要使用它。 :-)</item>

  <item>Conflicts:
  <p>除非与这个软件包冲突的软件包都已经被删除了，否则它不会被安装。如
     果一个软件包存在时你的程序不能被运行或者会出现严重的错误，就使用
     这个标签。</item>

  <item>Provides:
  <p>当多个软件包提供同一个功能时，可以定义一些虚拟的软件包名称。你可
     以在/usr/share/doc/debian-policy/virtual-package-names-list.txt.gz
     文件中找到一个完整的虚拟软件包列表。当你的软件包提供一个已经存在
     的虚拟软件包所需要的功能时，可以使用这个字段。</item>

  <item>Replaces:
  <p>当你的软件包会替换一些其它软件包的文件或者是整个软件包(与
     Confilicts:联用)时，可以使用这个字段。这里提到的软件包中的文件将
     会被你的软件包中的文件覆盖。</item>
  </list>

  <p>所有这些字段使用统一的语法格式：用逗号分隔的一系列软件包名称。这
     里的软件包名称可以是用竖线符号`<tt>|</tt>'分开的一系列可相互替换
     (alternative)的软件包名称。

  <p>对于每一个软件包的特定版本的要求也可以在这个字段中限制。只要在软
     件包的名称后写上括号并在括号中写明版本列表并在每一个版本号前注明
     当前软件包和它的关系就可以了。这里提到的关系可以是：
     <tt>&lt;&lt;</tt>、<tt>&lt;=</tt>、<tt>=</tt>、<tt>&gt;=</tt>和<tt>&gt;&gt;</tt>，
     它们分别表示先于、先于或等于、等于、晚于和晚于或等于。例如，

  <p><example>
  Depends: foo (>= 1.2), libbar1 (= 1.3.4)
  Conflicts: baz
  Recommends: libbaz4 (>> 4.0.7)
  Suggests: quux
  Replaces: quux (<< 5), quux-foo (<= 7.6)
  </example>
  
  <p>最后一个你需要知道的功能是${shlibs:Depends}。在你的软件包被创建并且
  安装到临时目录中以后，<manref name="dh_shlibdeps" section="1">
  将会扫描其中的二进制文件和库文件，检测它们对共享库的倚赖性，以及这些共
  享库所在的软件包，如libc6、xlib6g等。它将会把结果列表传递给
  <manref name="dh_gencontrol" section="1">，后者将会把这些信
  息填写到正确的位置上，你就不用为它操心了。

  <p>说了这么多，我们现在可以继续了，让Depends:这一行保持原状，并在它后面
  插入一行，在这一行中些上<tt>Suggests: file</tt>，因为gentoo可以使用这个程
  序/软件包提供的一些功能。

  <p>第11行是一个简短的描述。大多数人的屏幕都是80列宽的，所以描述文字不能
  超过大概60个英文字符长。我把它改成"A fully GUI configurable X file 
  manager using GTK+"。

  <p>第12行是一个比较长的描述。在这里可以写关于这个软件包的详细情况的一段
  话。每行的第1列应该是空白的。两行之间不能有空白行，如果真的想留一个空白
  行，可以通过写一个单独的小数点符号实现。还有，在长描述之后，不能有超过
  一行的空白。

  <p>最后，我们给出一个修改好的control文件：

  <p><example>
  1  Source: gentoo
  2  Section: x11
  3  Priority: optional
  4  Maintainer: Josip Rodin &lt;joy-mg@debian.org&gt;
  5  Build-Depends: debhelper (>> 3.0.0), xlibs-dev, libgtk1.2-dev, libglib1.2-dev
  6  Standards-Version: 3.5.2
  7
  8  Package: gentoo
  9  Architecture: any
  10 Depends: ${shlibs:Depends}
  11 Suggests: file
  12 Description: A fully GUI configurable X file manager using GTK+
  13  gentoo is a file manager for Linux written from scratch in pure C. It
  14  uses the GTK+ toolkit for all of its interface needs. gentoo provides
  15  100% GUI configurability; no need to edit config files by hand and re-
  16  start the program. gentoo supports identifying the type of various
  17  files (using extension, regular expressions, or the 'file' command),
  18  and can display files of different types with different colors and icons.
  19  .
  20  gentoo borrows some of its look and feel from the classic Amiga file
  21  manager "Directory OPUS" (written by Jonathan Potter).
  </example>
  (我为它增加了行号。)

  <sect id="copyright">`copyright' 文件

  <p>这个文件中包含着关于软件包的来自于上游的资源、版权和授权信息。它的格
  式在政策中并未dictated，关于它的内容是(13.6 "Copyright information").

  <p>dh_make将会创建一个缺省的，其内容如下：

  <p><example>
  1  This package was debianized by Josip Rodin &lt;joy-mg@debian.org&gt; on
  2  Wed, 11 Nov 1998 21:02:14 +0100.
  3
  4  It was downloaded from &lt;fill in ftp site&gt;
  5
  6  Upstream Author(s): &lt;put author(s) name and email here&gt;
  7
  8  Copyright:
  9
  10 &lt;Must follow here&gt;
  </example>
  (我为它增加了行号。)

  <p>在这个文件中需要增加的重要信息是你获得软件包的位置以及它原有的版权提
  示和授权协议。如果它的授权协议不是通用的自由软件授权协议如GNU的GPL或
  LGPL、BSD或者Artistic协议，你就必需把它的协议包含在这个文件中。而当它使
  用上述自由软件授权协议时，你可以直接引用/usr/share/common-licenses/目录
  中的相应文件，它们已经存在于Debian系统中了。

  <p>简而言之，下面是gentoo的copyright文件：

  <p><example>
  1  This package was debianized by Josip Rodin &lt;joy-mg@debian.org&gt; on
  2  Wed, 11 Nov 1998 21:02:14 +0100.
  3
  4  It was downloaded from: ftp://ftp.obsession.se/gentoo/
  5
  6  Upstream author: Emil Brink &lt;emil@obsession.se&gt;
  7
  8  This software is copyright (c) 1998-99 by Emil Brink, Obsession
  9  Development.
  10
  11 You are free to distribute this software under the terms of
  12 the GNU General Public License.
  13 On Debian systems, the complete text of the GNU General Public
  14 License can be found in the file `/usr/share/common-licenses/GPL'.
  </example>
  (我为它增加了行号。)

  <sect id="changelog">`changelog' 文件

  <p>这是一个必需的文件，它的格式已经在政策文件的4.4节"debian/changelog"
  中说明了。dpkg和其它需要获取你的软件包的版本号、修订号、发行版和紧急度
  的程序会需要使用这个格式。

  <p>对你而言，它也是非常重要的，因为它可以让你写下所有你所做的所有变更。
  这可以帮助下载了你的软件包的人们了解软件包中是否有它们应该知道的问题。
  在二进制版本的软件包中，它会被保存在
  `/usr/share/doc/gentoo/changelog.Debian.gz'文件中。

  <p>dh_make创建了一个缺省的，如下所示：

  <p><example>
  1  gentoo (0.9.12-1) unstable; urgency=low
  2
  3   * Initial Release.
  4
  5  -- Josip Rodin &lt;joy-mg@debian.org&gt;  Wed, 11 Nov 1998 21:02:14 +0100
  6
  </example>
  (我为它增加了行号。)

  <p>第1行是软件包的名称、版本、发行版和紧急度。这里的名称必需和源代码包
  的名称相同，发行版应当是`unstable'(或者`experimental')，urgency应当改成
  任何比`low'高一些级别的内容。 :-)  
  
  <p>第3到5行是一个很长的项目，在这里你可以写下你对这个版本的软件说做的修
  改(不包括上游修改——有专门的由作者创建的文件来记录它们，稍后你将会把它
  安装到/usr/share/doc/gentoo/changlog.gz)。新的内容必需插入在最上方的星
  号(`*')前。你可以用<manref name="dch" section="1">来做或者用
  一个文本编辑器手工修改。

  <p>最后，你的文件应该是下面的样子：

  <p><example>
  1  gentoo (0.9.12-1) unstable; urgency=low
  2
  3   * Initial Release.
  4   * This is my first Debian package.
  5   * Adjusted the Makefile to fix $DESTDIR problems.
  6
  7  -- Josip Rodin &lt;joy-mg@debian.org&gt; Wed, 11 Nov 1998 21:02:14 +0100
  8
  </example>
  (我为它增加了行号。)

  <p>在后面的更新<ref id="update">中你可以找到更多关于更新changelog的内容。
  
  <sect id="rules">`rules' 文件

  <p>现在我们需要来看看<manref name="dpkg-buildpackage" section="1">用来
  创建软件包的精确规则了。这个实际上是另一个Makefile脚本，但同上游源代码
  中的那个不同。与debian/目录中的其它文件不同的是这个文件有可执行标记。

  <p>就象其它的Makefile一样，每个`rules'文件都有一些用来指导如何处理源代
  码的规则。每个规则都由目标、文件名或者是需要执行的操作的名称(如
  `build:'、`install:')组成。当你要执行一个规则时可以在命令行参数上加入参
  数(比如`./debian/rules build` 或者 `make -f rules install`)。在目标名称
  之后，你可以写这个规则对程序活文件的倚赖性。之后，可以有任意数目的命
  令，这些命令要用&lt;tab&gt;符号缩进。新的规则以位于第一列上目标声明开
  始。空白行和以`#'(井字号)开始的行将会被作为注释忽略掉。

  <p>现在你可能已经听糊涂了，但只要看一下dh_make为我们创建的缺省的`rules'
  文件你就能明白了。另外你也应该读一下info中的`make'项目来获得更多的信息。

  <p>有一个关于dh_make所创建的rules文件你的重要问题是你应该知道的：它只
  是一个建议版本。对于一些简单的软件包它可以工作，但对于稍为复杂一些的，
  应当敢于增加或者删减其内容使其符合你的需求。唯一你不能修改的就是规则的
  名称，因为政策手册中提到的所有工具都将使用它们。

  <p>这里是dh_make为我们产生的缺省的debian/rules文件：

  <p><example>
  1  #!/usr/bin/make -f
  2  # Sample debian/rules that uses debhelper.
  3  # GNU copyright 1997 to 1999 by Joey Hess.
  4
  5  # Uncomment this to turn on verbose mode.
  6  #export DH_VERBOSE=1
  7
  8  # This is the debhelper compatibility version to use.
  9  export DH_COMPAT=4
  10 
  11 CFLAGS = -g
  12 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
  13 CFLAGS += -O0
  14 else
  15 CFLAGS += -O2
  16 endif
  17
  18 build: build-stamp
  19 build-stamp:
  20    dh_testdir
  21
  22    # Add here commands to compile the package.
  23    $(MAKE)
  24    #/usr/bin/docbook-to-man debian/gentoo.sgml > gentoo.1
  25
  26    touch build-stamp
  27
  28 clean:
  29    dh_testdir
  30    dh_testroot
  31    rm -f build-stamp
  32
  33    # Add here commands to clean up after the build process.
  34    -$(MAKE) clean
  35
  36    dh_clean
  37
  38 install: build
  39    dh_testdir
  40    dh_testroot
  41    dh_clean -k
  42    dh_installdirs
  43
  44    # Add here commands to install the package into debian/gentoo.
  45    $(MAKE) install DESTDIR=$(CURDIR)/debian/gentoo
  46
  47 # Build architecture-independent files here.
  48 binary-indep: build install
  49 # We have nothing to do by default.
  50
  51 # Build architecture-dependent files here.
  52 binary-arch: build install
  53    dh_testdir
  54    dh_testroot
  55 #  dh_installdebconf
  56    dh_installdocs
  57    dh_installexamples
  58    dh_installmenu
  59 #  dh_installlogrotate
  60 #  dh_installemacsen
  61 #  dh_installpam
  62 #  dh_installmime
  63 #  dh_installinit
  64    dh_installcron
  65    dh_installman
  66    dh_installinfo
  67 #  dh_undocumented
  68    dh_installchangelogs ChangeLog
  69    dh_link
  70    dh_strip
  71    dh_compress
  72    dh_fixperms
  73 #  dh_makeshlibs
  74    dh_installdeb
  75 #  dh_perl
  76    dh_shlibdeps
  77    dh_gencontrol
  78    dh_md5sums
  79    dh_builddeb
  80
  81 binary: binary-indep binary-arch
  82 .PHONY: build clean binary-indep binary-arch binary install
  </example>
  (我为它增加了行号。)

  <p>对于第1行你一定很熟悉，因为它和shell及Perl脚本很象。它告诉操作系统
  这个文件应当交给/usr/bin/make来处理。

  <p>第6到9行上提到的DH_*变量应当被evident从简短的说明。要想知道关于
  DH_COMPAT的更多信息，可以阅读<manref name="debhelper" section="1">
  手册中关于"Debhelper compatibility levels"一节。

  <p>第11到16行是一个支持DEB_BUILD_OPTIONS的骨架，它的描述可以在政策文档
  的第11.1节"Binaries"中找到。简单的说，它们控制着在构造二进制文件的时候
  是否要加入调试符号，是否要在安装的时候进行裁减。再重复一下，这只是一个
  骨架，一个你应当做这件事的提示。你需要找出上游的构建系统是如何处理调试
  符号和安装裁减的，然后自己实现它们。

  <p>一般情况下，你可以通过CFLAGS变量来让gcc在编译的时候使用"-g"选项——
  如果这是你的软件包的情况，你可以把<tt>CFLAGS="$(CFLAGS)"</tt>附加到
  $(MAKE)调用的<em>后面</em>来propagete这个变量(看下面)。还有另外一种方
  法，如果你的软件包使用了autoconf脚本，你可以把通过给./configure调用加上
  <em>前缀</em>来把它传递给构建规则。

  <p>关于裁减的问题，一般情况下程序自己的安装配制都不会进行裁减，而且通常
  也不会包含一个选项让 你来做这件事情。幸运的是，你有
  <manref name="dh_strip" section="1">，而且当你设定了
  DEB_BUILD_OPTIONS=nostrip时，他会安静地退出。

  <p>第18到26行描述了`build'(和`build-stamp')规则，它们运行应用程序自己的
  Makefile来编译它。稍后在<ref id="manpage">中我们会讨论docbook-to-man的
  例子。

  <p>第28到36行的`clean'规则会清除所有不需要的二进制文件和自动产生的东
  西，在每次构建软件包的时候都会首先执行。这个规则必须在所有的时候都能正
  常工作(即便源代码目录已经<em>是</em>清理被清理好的)，所以请使用强制选项
  (比如对于rm是`-f')，或者通过在命令的名字前加上`-'让make忽略返回值(失
  败)。

  <p>`install'规则从第38行开始，它指导了安装过程。它通常去执行软件自己的
  Makefile中的`install'规则，但会把软件包安装在<tt>$(CURDIR)/debian/gentoo</tt>
  目录中——这就是为什么我们要在gentoo的Makefile中指定$(DESTDIR)作为安装
  的跟目录。

  <p>就象注释中说明的那样，第48行上的`binary-indep'规则是用来构建体系结构
  无关的软件包的。因为这里我们并没有这样的软件包，所以什么都不用做了。

  <p>在52-79行上是下一条规则`binary-arch'，在这里我们运行了好几个
  debhelper软件包中的小工具，它们将会在你的软件包上执行不同的操作来使其符
  合政策。

  <p>如果你的软件包是`Architecture: all'的，那么你需要在`binary-indep'中
  包含所有的命令，而让`binary-arch'保持空白。
  
  <p>debhelper程序都是以dh_开始的，剩下的部分描述了这个工具具体的作用。其
  实它们的名字都已经说的很清楚了，但这里我们还是给出一些额外的解释：

  <list>
  <item><manref name="dh_testdir" section="1">检查你是不是在正确的目录中
  (比如源代码目录的最上层)；
  <item><manref name="dh_testroot" section="1">检查你是否拥有在`binary-arch'、
        `binary-indep'和`clean'时需要用到的root权限；
  <item><manref name="dh_installman" section="1">把手册页文件复制到正确
  的目标目录中你不需要告诉它究竟相对于最高层源代码目录的那个位置
  是哪里；
  <item><manref name="dh_strip" section="1">从可执行文件和库文件中裁减掉
  调试信息，使它们更小一些；
  <item><manref name="dh_compress" section="1">用<manref name="gzip"
        section="1">压缩所有大于4 kB的手册页和文档；
  <item><manref name="dh_installdeb" section="1">把与软件包相关的所有文
  件(例如维护脚本)复制到<file>debian/gentoo/DEBIAN</file>目录中；
  <item><manref name="dh_shlibdeps" section="1">计算库文件和可执行文件
  对共享库的倚赖性；
  <item><manref name="dh_gencontrol" section="1">在控制文件插入一个已经
  格式化(fine-tuned)好的<file>debian/gentoo/DEBIAN</file>文件;
  <item><manref name="dh_md5sums" section="1">为软件包中的所有文件产生
  MD5校验码。
  </list>

  <p>要想了解更完整的的关于这些dh_*脚本究竟会做什么的信息以及它们其它的选
  项，请阅读它们相应的手册。还有一些可能是非常有用的dh_*脚本文件在这里没
  有提及。如果你需要使用它们，情阅读debhelper的文档。

  <p>在binary-arch一节中，你必须要注释掉或者删除掉你不需要的功能调用。对
  于gentoo，我把关于examples、cron、init、man和info的行注释掉了，因为
  gentoo根本不需要它们。而且在第68行上，我把`ChangeLog'换成了`FIXES'，因
  为那是上游的changelog文件的真实名字。

  <p>最后的两行(和其它这里未曾解释的地方)是需要的，在make的手册和Debian政
  策文件都是可以找到。现在知道它们的作用并不重要。

  <chapt id="dother">debian/中的其它文件

  <p>你会看到在debian/子目录中还有几个已经存在的文件，它们大多数都是以
  `.ex'结尾的，表明它们只是例子。仔细看一下它们。如果你希望使用其中任何一
  个功能，你需要做的事情是：

  <list>
    <item>看一下相关的文档(提示：Debian政策手册)，
    <item>如果需要就修改文件使其符合你的需求，
    <item>修改文件名如果有`.ex'后缀就去掉它，
    <item>如果需要就修改`rules'文件。
  </list>

  <p>在下面给出了一些经常会被用到的文件的解释。

  <sect id="readme">README.Debian

  <p>所有的在原来的软件包和你的debian版本的软件包之间的细节及
  discrepancies需要写在这里。

  <p>dh_make创建了一个缺省的，如下所示：

  <p><example>
  gentoo for Debian
  -----------------

  &lt;possible notes regarding this package - if none, delete this file&gt;

   -- Josip Rodin &lt;joy-mg@debian.org&gt;, Wed, 11 Nov 1998 21:02:14 +0100
  </example>

  <p>由于我们不需要在这里写任何东西，我们就把它删掉了。

  <sect id="conffiles">conffiles.ex

  <p>关于软件，有一件事情是很烦人的，那就是当你花费了很多的时间和精力定制
  好一个程序，只要一升级，你所有的定制就都会被stomp了。Debian解决这个问题
  的方法是标注出配制文件，这样当你升级一个软件包时，你将会被询问是否要保
  留你原来的配制文件。

  <p>如果希望对让一个软件包可以做到这点，只要把每一个配制文件(通常在
  /etc)目录下的完整路径逐行加入到一个名叫<tt/conffiles/的文件里面就可以
  了。Gentoo有一个配制文件，/etc/gentoorc，我们把他加入到文件<tt/conffiles/
  中。

  <p>如果你自己的程序有一个配制文件并且会自己覆盖它，那么最好就不要把它标
  记为配制文件了，因为这样dpkg就总会会询问用户是否要修改它。

  <p>如果你的软件包总要求每个用户修改自己的配制文件，最好也不要把配制文件
  标记出来了。

  <p>你可以用用`maintainer scripts'来处理例子配制文件，要了解更多的信息请
  参考<ref id="maintscripts">。
  
  <p>如果你的程序根本没有conffiles，对你来说从debian/目录中删除<tt/conffiles/
  就是很安全的了。

  <sect id="crond">cron.d.ex

  <p>如果你的软件包需要计划任务正常运行才能够正常操作，你可以在这个文件中
  设置它。

  <p>注意这里并不包括定期清除日志的任务；关于它，请参考
  <manref name="dh_installlogrotate" section="1">和
  <manref name="logrotate" section="8">。

  <p>如果你不需要，那就把它删了吧。

  <sect id="dirs">dirs

  <p>这个文件里指出了我们需要的但常规的安装过程(make install)并不会自动创
  建的目录。

  <p>缺省情况下，它的内容如下所示：

  <p><example>
  usr/bin
  usr/sbin
  </example>

  <p>注意最前面是没有斜线的。我们通常把它改成下面的样子：

  <p><example>
  usr/bin
  usr/man/man1
  </example>
  
  <p>但这些目录在Makefile中已经创建了，所以我们不需要这个文件，并且打算把
  它删了。

  <sect id="docs">docs

  <p>在这个文件中，我们可以指定一些让dh_installdocs帮我们安装到临时目录中
  的文档的文件名。

  <p>缺省的情况下，他会包含所有已经存在于源代码目录最高层目录中的名为
  "BUGS"、"README*"、"TODO"等的文件。

  <p>对于gentoo，我们还加入了一些其它的内容：

  <p><example>
  BUGS
  CONFIG-CHANGES
  CREDITS
  ONEWS
  README
  README.gtkrc
  TODO
  </example>
  
  <p>我们可以删掉这个文件，取而代之的是在<tt/rules/文件中的
  <tt/dh_installdocs/命令后列出这里提到的文件的名字，如下所示：

  <p><example>
        dh_installdocs BUGS CONFIG-CHANGES CREDITS ONEWS README \
                       README.gtkrc TODO
  </example>

  <p>也许并不像你看到的这样，你自己的软件包可能根本就没有这些文件。在这种
  情况下，对你来说删掉这个文件是很安全的。但是不要删掉<tt/rules/文件中的
  <tt/dh_installdocs/，因为它还要被用于安装<tt/copyright/和其它的一些东西。

  <sect id="emacsen">emacsen-*.ex

  <p>如果你的软件包提供了一些可以在安装时进行字节编译的Emacs文件，你可以
  使用这些文件来设置它们。

  <p>通过命令<manref name="dh_installemacsen" section="1">可以把它们安装到临时文件
  中，所以如果你要使用它不要忘了去掉<tt/rules/文件中那一行上的注释。

  <p>如果你不需要这些，删掉它们。

  <sect id="initd">init.d.ex

  <p>如果你的软件包是一个需要在系统启动时运行的守护程序，那么很显然你没有
  采纳我在开始时的建议，不是吗？ :-)

  <p>这是一个<file>/etc/init.d/</file>脚本的通用骨架，所以你不得不对它进
  行大规模的修改。通过<manref name="dh_installinit" section="1">
  可以把它安装到临时目录中。

  <p>如果你不需要这些，删掉这个文件。

  <sect id="manpage">manpage.1.ex, manpage.sgml.ex

  <p>你的程序应该有一个手册页。如果它们没有，这里的每一个文件都是一个模
  板，你只要把它填好就可以了。

  <p>手册页通常用<manref name="nroff" section="1">写成。<tt/manpage.1.ex/
  这个例子也使用nroff写的。在<manref name="man" section="7">的手册页中可
  以找到一个关于如何编写这样一个文件的简短说明。
  
  <p>如果你更希望些SGML而不时nroff，那么你可以使用<tt/manpage.sgml.ex/模
  板。如果是这样，那么你就必需做下面这些事情：
  <list>
    <item>安装软件包<package/docbook-to-man/
    <item>把<tt/docbook-to-man/加到<tt/control/文件的<tt/Build-Depends/一行。
    <item>删除<tt/rules/文件`build'规则中docbook-to-man调用前的注释
  </list>

  <p>另外还要记得把文件名改成类似于<tt/gentoo.sgml/的样子！

  <p>最后，手册页文件的名字应该包含它所描述的程序的名字。所以我们需要把
  "manpage"改成"gentoo"。这个文件明中还以一个".1"作为后缀，这表明它是一
  个关于用户命令的手册。一定要确保这个节编号是正确的。这里有一个关于手册
  页各个节的简短列表：

  <p><example>
  Section |     Description     |     Notes
     1     User commands          Executable commands or scripts.
     2     System calls           Functions provided by the kernel.
     3     Library calls          Functions within system libraries.
     4     Special files          Usually found in /dev
     5     File formats           E.g. /etc/passwd's format
     6     Games                  Or other frivolous programs
     7     Macro packages         Such as man macros.
     8     System administration  Programs typically only run by root.
     9     Kernel routines        Non-standard calls and internals.
  </example>
  
  <p>所以gentoo的手册页应该叫做<tt/gentoo.1/。对于X的程序，你可以在原来的
  节编号后面加上一个"x"，例如<tt/gentoo.1X/。在原来的源程序中，并没有
  gentoo.1的手册页，所以我利用例子和上游文档给出的信息写了一个。

  <sect id="menu">menu.ex

  <p>X窗口系统的用户通常都会使用支持菜单的窗口管理器，这些菜单可以被定制
  用于启动程序。如果它们安装了Debian的<package/menu/软件包，那么系统就会
  创建一套包含有系统上每一个程序的菜单。 

  <p>这里有一个缺省的由dh_make创建的<tt/menu.ex/文件：
  
  <p><example>
  ?package(gentoo):needs=X11|text|vc|wm section=Apps/see-menu-manual\
    title="gentoo" command="/usr/bin/gentoo"
  </example>

  <p>在冒号之后的第一个字段是"needs"，他指明了程序需要什么样的界面。可以
  把这个字段改成一个合适的值，比如"text"或者"X11"。

  <p>下面是"section"，它指出这个项目应当出现的菜单和子菜单。当前的可选节
  被列在文件<file>/usr/share/doc/debian-policy/menu-policy.html/ch2.html#s2.1</file>
  中。

  <p>"title"字段是程序的名字。如果你喜欢，可以用大写字母开头。但一定要使
  他保持简短。

  <p>最后，"command"字段用于运行程序。

  <p>现在我们要把菜单项改成下面的样子：

  <p><example>
  ?package(gentoo): needs=X11 section=Apps/Tools title="Gentoo" command="gentoo"
  </example>

  <p>你还可以加入其它的字段，比如"longtitle"、"icon"、"hints"等。
  参考<manref name="menufile" section="5">、<manref name="update-menus" section="1">和
  <file>/usr/share/doc/debian-policy/menu-policy.html/</file>可以了解更多信息。

  <sect id="watch">watch.ex

  <p>这个文件用于配制程序<manref name="uscan" section="1">和
  <manref name="uupdate" section="1">(在软件包<package/devscripts/中)。它们可以用
  于监视你下载源代码的站点。

  <p>这里是我的配制：

  <p><example>
  # watch control file for uscan
  # Site                Directory       Pattern                 Version Script
  ftp.obsession.se      /gentoo         gentoo-(.*)\.tar\.gz    debian  uupdate
  </example>

  <p>提示：在创建了这个文件后，可以连接到Internet，并且试着在程序目录中运
  行"uscan"命令。还要读手册哦！:)

  <sect id="doc-base">ex.package.doc-base

  <p>如果你的软件包还有除了手册页以外的其它普通文档和info文档，你需要使用
  `<package/doc-base/'文件来注册它们，这样用户就能够用如<manref name="dhelp" section="1">、
  <manref name="dwww" section="1">或者<manref name="doccentral" section="1">
  等工具来找到它们。

  <p>这通常包括<file>/usr/share/doc/packagename/</file>中的HTML、PS和PDF文件。

  <p>gentoo的doc-base文件如下所示：

  <p><example>
  Document: gentoo
  Title: Gentoo Manual
  Author: Emil Brink
  Abstract: This manual describes what Gentoo is, and how it can be used.
  Section: Apps/Tools

  Format: HTML
  Index: /usr/share/doc/gentoo/html/index.html
  Files: /usr/share/doc/gentoo/html/*.html
  </example>

  <p>关于安装的文件格式，请参考<manref name="install-docs" section="8">
  和<file>/usr/share/doc/doc-base/doc-base.html/</file>中的
  <package/doc-base/手册。

  <sect id="maintscripts">postinst.ex, preinst.ex, postrm.ex, prerm.ex

  <p>这些文件叫做维护者脚本。它们被放在软件包的控制区域中，并且在你的软件
  包被安装、升级或删除时由<prgn/dpkg/调用。

  <p>现在，你应该尽可能避免修改任何维护者脚本，因为它们有一些复杂。要了解
  关于它们的更多信息请参考政策手册的第6章，而且还应该看看dh_make所提供的
  例子文件。

  <chapt id="build">构建软件包

  <p>现在我们已经为构件软件包做好了准备。

  <sect id="completebuild">完整的rebuild

  <p>进入程序的主目录然后运行如下命令：

  <p><example>
  dpkg-buildpackage -rfakeroot
  </example>

  <p>这将为你做好每件事情。它会：
  <list>
    <item>清理源代码目录树(debian/rules clean)，需要使用<prgn/fakeroot/
    <item>构件源代码软件包(dpkg-source -b)
    <item>构件程序(debian/rules build)
    <item>构件二进制软件包(debian/rules binary)，需要使用<prgn/fakeroot/
    <item>用文件<tt/.dsc/给源代码签名，需要使用<prgn/gnupg/
    <item>创建上传文件<tt/.changes/并给它签名，需要使用
          <prgn/dpkg-genchanges/和<prgn/gnupg/
  </list>

  <p>唯一需要你输入的是你的GPG密钥的密码，两次。

  <p>当完成所有这些，你会在上一层目录(<tt>~/debian/</tt>)中看到下面的文件：

  <p><list>
  <item><em>gentoo_0.9.12.orig.tar.gz</em>

  <p>这是原来的源程序的压缩包，为了遵守Debian的标准，修改了它的文件名。注
  意它是我们通过在开始时运行带有`-f'参数的<prgn/dh_make/命令创建的。

  <item><em>gentoo_0.9.12-1.dsc</em>

  <p>这时对源代码的一个总结。这个程序是利用你的`control'文件创建的，并且
  在用<manref name="dpkg-source" section="1">命令解包源代码时将会用到。这
  个文件已经有了
  PGP签名，这样人们就可以确认他是你发布的。

  <item><em>gentoo_0.9.12-1.diff.gz</em>

  <p>这个文件中包含了每一个你对原始源代码所做的每一个修改，它的格式是
  "unified diff"。他是由<manref name="dpkg-source" section="1">程序创建
  的，而且这个程序还要使用它。警告：如果你没有把原始的源代码压缩包的名字
  改成packagename_version.orig.tar.gz，<prgn/dpkg-source/将不能正确地创建
  这个.diff.gz文件。

  <p>如果其它人希望重头重新构造你的软件包，它们可以用上面的三个文件很容易
  地做到。解包的过程很简单：只要把这三个文件复制到一个别的什么地方，然后
  运行<tt>dpkg-source -x gentoo_0.9.12-1.dsc</tt>.

  <item><em>gentoo_0.9.12-1_i386.deb</em>

  <p>这是你的完整的二进制软件包。你可以象对待其它软件包一样用
  <prgn/dpkg/命令安装和删除它。

  <item><em>gentoo_0.9.12-1_i386.changes</em>

  <p>这个文件描述了描述了所有对当前版本的修订版所作的改动，Debian
  FTP文档维护程序在安装二进制版本软件包和源代码版本的软件包时将会
  使用到它。它的一部分是通过`changelog'文件和.dsc文件创建的。这个
  文件已经有了PGP签名，这样人们可以确信它确实是你的。

  <p>因为你会继续花精力在这个软件包上，它的行为可能会改变，还有可
  能会增加一些新的功能。下载了你的软件包的人们可以通过阅读这个文件
  从而快速的了解到什么东西发生了变化。Debian的文档维护程序也会把这
  个文件的内容发送到debian-devel-changes邮件列表上。
  </list>

  <p>.dsc和.changes文件中的长数字字符串是上面提到的文件的MD5校验码。下载
  了你的文件的人可以用<manref name="md5sum" section="1">来检查这些数字是
  否相同，这样它们就可以知道文件是不是损坏了，或者是否被tampered with了。

  <sect id="quickrebuild">快速rebuild

  <p>对于一个很大的软件包，你可能不希望在你调整了<file>debian/rules</file>
  文件的一些细节后都从头来构建它。为了测试，你可以只制作一个.deb文件而不
  重新构造上游源代码，具体的作法如
  下所示：

  <p><example>
  fakeroot debian/rules binary
  </example>

  <p>一旦你完成了调整，记得要根据上面的内容从头以正确的顺序重新构
  建软件包。如果你想上传一个以这种方式制作的.deb文件时可能会遇到错
  误。

  <chapt id="checkit">检查软件包中的错误

  <p>在你的.changes文件上运行<manref name="lintian" section="1">；
  这个程序将会检查出软件包中的一些很常见的错误。它的命令是：
  
  <p><example>
  lintian -i gentoo_0.9.12-1_i386.changes
  </example>
  
  <p>当然，要用为你的软件包产生的.changes文件的文件名替换掉上面的。如果这
  个命令的运行结果显示在软件包中有错误(以E:开始的行)，清仔细阅读关于错误
  的说明(以N:开始的行)，纠正错误，然后根据前文<ref id="completebuild">所
  述重新构建软件包。如果在输入的信息中有以W:开始的行，它们代表警告，那就
  要调整软件包或者如果你确认这些警告是不是spurious的(让Lintianoverride它
  们；请参考文档以获得更多的信息。)
 
  <p>注意你可以用一个命令<manref name="debuild" section="1">完成构建软件包
  <prgn/dpkg-buildpackage/和运行<prgn/lintian/这两个任务。

  <p>用一个类似于<manref name="mc" section="1">的文件管理器来仔细看一下软
  件包的内容，或者用<manref name="dpkg-deb" section="1">把它解包到一个临时的位置。
  仔细在二进制软件包 和源代码软件包中找找有没有没用的文件。通常cruft都不
  会被清理的很干净；调整你的rules文件来compensate它。小技巧：
  `zgrep ^+++ ../gentoo_0.9.12-1.diff.gz`会列出你对源代码所做的修改的列
  表，而`dpkg-deb -c gentoo_0.9.12-1_i386.deb`会给出二进制包中的文件列表。

  <p>自己安装你的软件包，比如用root的身份使用<manref name="debi" section="1">命令。
  尝试在其它的机器上而不只是你自己的机器上安装并运行你的软件包，并仔细观
  察所有的在安装和运行时系统给出的错误信息。

  <chapt id="upload">上传软件包

  <p>现在你已经完整地测试过你的新软件包了，你可以开始Debian新维护者申请
  的过程，<url id="http://www.debian.org/devel/join/newmaint">讲述了这个
  过程。  

  <p>一旦你成为正事的开发人员，你就可以上传软件包到Debian文档中了。你可以
  手工做这件事情，但如果使用一些已经提供的自动化工具(比如<manref name="dupload" section="1">
  和<manref name="dput" section="1">)，这个过程将会变得更容易。我们将仔细
  描述如何使用<prgn/dupload/来完成这一任务。

  <p>首先你必需设定dupload的配制文件。你可以修改会影响整个系统的文件
  <file>/etc/dupload.conf</file>，或者是创建一个属于你自己的文件
  <file>~/.dupload.conf</file>，来覆盖系统文件中一些你希望修改的部分。把
  下面的内容添加到文件中去： 

  <p><example>
  package config;

  $default_host = "ftp-master";

  $cfg{"ftp-master"}{"login"} = "yourdebianusername";

  $cfg{"non-us"}{"login"} = "yourdebianusername";

  1;
  </example>

  <p>当然，要把我的个人设置改成你的，再阅读一下<manref name="dupload.conf" section="5">的手册，
  搞懂这里的每一个选项是什么意思。

  <p>设定$default_host选项是最有窍门的——它会自动检查缺省情况下究竟使用
  哪一个上传序列。"ftp-master"是一个主序列，但很有可能你会希望能够使用另
  外一个更快的。
  要了解关于上传序列(queues)的更多内容，请阅读位于
  <file>/usr/share/doc/developers-reference/developers-reference.html/ch-upload.en.html#s-uploading</file>
  的开发人员参考中"Uploading a package"一节。


  <p>然后连接到你的Internet服务提供商，并且运行下面的命令：
  
  <p><example>
  dupload gentoo_0.9.12-1_i386.changes
  </example>

  <p><prgn/dupload/会检查文件的MD5校验码是否和.changes文件中的相同，正因为此，
  它才会象在<ref id="completebuild">中所述警告你重新构建软件包，
  只有这样它才能正常上传软件包。

  <p>如果你上传到服务器"ftp-master"，<prgn/dupload/会询问你在那台Debian服务器
  上的密码，然后自动上传它。

  <chapt id="update">更新软件包

  <sect id="newrevision">新的Debian修订版

  <p>现在我们假设有人提交了一个关于你的软件包的bug报告，第#54321号，它描
  述了一个你可以解决的问题。要为你的软件包创建一个新的Debian修订版，你需
  要：

  <list>
  <item>当然，必需更正软件包的源代码中的问题。

  <item>在Debian changelog文件中增加一个新的修订版，比如通过
  命令`dch -i`或者是`dch -v &lt;version&gt;-&lt;revision&gt;`。
  然后用你喜欢的文本编辑器插入新的关于修改的注释信息。

  <p>小技巧：如何才能方便地以希望的格式得到日期呢？使用
  `822-date`或者是`date -R`。

  <item>在changelog的项目上包含一份对bug的简短描述以及解决方
  法，并将它附加在"Closes: #54321"之后。这样，当你的软件包被
  Debian文档库接受的时候，这个bug报告将会被文档维护软件自动关
  闭。
  
  <item>重复你在<ref id="completebuild">、<ref id="checkit">和
  <ref id="upload">中所做的。不同的是这一次，原始的源代码将不
  会被包括，因为它们并没有被修改并且已经存在于Debian的文档库中
  了。
  </list>

  <sect id="newupstream">新的上游版本

  <p>现在我们来考虑另外一种情况，一种稍微复杂一点的情况——一个上游的版本
  发布了，当然你会希望它能够被打包。你需要做下面的事情：

  <list>
  <item>下载新版本的源代码，并将它的压缩包(比如
  `gentoo-0.9.13.tar.gz')放到原先的源代码目录树的上层目录中
  (比如~/debian/)。 

  <item>进入旧的源代码目录，并且运行下面的命令：

  <example>
  uupdate -u gentoo-0.9.13.tar.gz
  </example>

  <p>当然用你的新程序的文档名称替换掉这里的文件名。<manref name="uupdate" 
  section="1">将会修改这个压缩包的名字，还会试着将原先
  .diff.gz文件中的所有的修改应用到它上面，并且会更新新的
  debian/changelog文件。

  <item>更换到目录`../gentoo-0.9.13'中，它是新的软件包源码目
  录树，重复你在<ref id="completebuild">、<ref id="checkit">
  和<ref id="upload">中所做的。
  </list>

  <p>注意如果你已经如<ref id="watch">所述建立了一个`debian/watch'文件，那
  么你就可以通过运行<manref name="uscan" section="1">来自动检测新版本的源
  代码并下载它们，然后运行<prgn/uupdate/。

  <sect id="upgrading">校验软件包的升级

  <p>当你创建了一个软件包的新版本，你必需做下面的事情来确认所有的人都可以
  安全的升级：

  <list>
    <item>从原先的版本升级，
    <item>降级到原先的版本并删除它，
    <item>安装新的软件包，
    <item>删除它然后重新安装它一遍，
    <item>彻底清楚它。
  </list>

  <p>注意如果你以前的软件包已经被发布到Debian，人们会通常会更新到Debian最
  新的发布中的那个版本上，所以要记得测试从那个版本升级的情况。

  <chapt id="helpme">在哪里可以找到帮助

  <p>在你决定要在一些公共地方提出你的问题时，请先RTFM。包括在
  <file>/usr/share/doc/dpkg</file>、<file>/usr/share/doc/debian</file>、
  <file>/usr/share/doc/package/*</file>等目录中的文档和所有在文档中提及的程序的
  man/info页面。

  <p>如果你有一些关于软件打包的问题，但却无法从文档中找出答案，你可以在
  Debian Mentors邮件列表上提出你的问题，邮件列表在
  <email/debian-mentors@lists.debian.org/。一些经验更丰富的Debian开发人员
  将会很高兴地帮助你，但在问问题前你要确定确实至少读过一些文档！

  <p>更多的关于这个邮件列表的信息可以在
  <url id="http://lists.debian.org/debian-mentors/">找到。

  <p>当你收到一个bug报告(是的，真正的bug报告！)，就是需要你去
  <url name="Debian Bug Tracking System" id="http://www.debian.org/Bugs/">
  看看并读一下那里的文档的时候了，这样你才能高效地处理bug。我强烈建议你阅
  读一下开发人员手册中"Handling Bugs"一节，它位于
  <file>/usr/share/doc/developers-reference/developers-reference.html/ch-bug-handling.en.html</file>。

  <p>如果你仍然有问题，可以在Debian开发人员邮件列表上把它提出来，这个邮件
  列表位于<email/debian-devel@lists.debian.org/。要想了解更多关于这个邮件
  列表的信息，请参考<url id="http://lists.debian.org/debian-devel/">。

  <p>即便所有的东西都工作正常，也到了你祈祷的时候了。为什么？因为在几小时
  (或者几天)之后，全球各地的Debian用户将会开始使用你的软件包，如果你犯了
  一些严重的错误，那么你的邮箱就会因受到太多愤怒的用户的抱怨而爆炸……
  笑笑吧。 :-)

  <p>放松一下然后为接受bug报告做准备吧，因为在你的软件包能够完全符合
  Debian的各种政策之前还有很多工作要做呢(再说一遍，一定要阅读<em>文档原文</em>
  来了结详细信息哦)。祝你好运！

 </book>

</debiandoc>