目录
Debian 的质量很大程度上归功于 Debian 策略，它定义了所有 Debian 软件包必须满足的明确基线要求。然而，也存在超越 Debian 策略的共享经验历史，这是多年打包经验的积累。许多才华横溢的人创建了出色的工具，这些工具可以帮助您，Debian 维护者，创建和维护优秀的软件包。
本章为 Debian 开发者提供了一些最佳实践。所有建议都仅仅是建议，而不是要求或策略。这些只是一些来自 Debian 开发者的主观提示、建议和指导。您可以随意挑选和选择最适合您的内容。
以下建议适用于 debian/rules 文件。由于 debian/rules 控制构建过程并选择进入软件包的文件（直接或间接），因此它通常是维护者花费最多时间的文件。
在 debian/rules 中使用辅助脚本的基本原理是，它们允许维护者在许多软件包之间使用和共享通用逻辑。例如，以安装菜单项的问题为例：您需要将文件放入 /usr/share/menu（或者，如果需要，对于可执行二进制 menufiles，则放入 /usr/lib/menu），并添加命令到维护者脚本以注册和注销菜单项。由于这对于软件包来说是非常常见的事情，为什么每个维护者都应该自己重写所有这些，有时还带有错误？此外，假设菜单目录更改了，每个软件包都必须更改。
辅助脚本处理这些问题。假设您遵守辅助脚本期望的约定，辅助脚本将处理所有细节。策略中的更改可以在辅助脚本中进行；然后软件包只需要使用新版本的辅助脚本重新构建，而无需其他更改。
附录 A, Debian 维护者工具概览 包含几个不同的辅助工具。最常见和最好的（我们认为）辅助系统是 debhelper。以前的辅助系统，例如 debmake，是单片的：您无法选择和挑选您认为有用的辅助工具的哪个部分，而必须使用辅助工具来完成所有事情。debhelper，然而，是许多独立的 dh_* 程序。例如，dh_installman 安装和压缩 man 页面，dh_installmenu 安装菜单文件，等等。因此，它提供了足够的灵活性，以便能够在有用的地方使用小的辅助脚本，并结合 debian/rules 中的手工命令。
您可以阅读 debhelper(1)，并查看软件包附带的示例，开始使用 debhelper。dh_make，来自 dh-make 软件包（参见 第 A.3.2 节，“dh-make”），可用于将 vanilla 源代码包转换为 debhelper 化的软件包。但是，这种快捷方式不应让您认为您不需要费心去理解各个 dh_* 辅助工具。如果您要使用辅助工具，您确实需要花时间学习如何使用该辅助工具，学习它的期望和行为。
有些人认为 vanilla debian/rules 文件更好，因为您不必学习任何辅助系统的复杂性。这个决定完全取决于您。使用对您有效的方法。许多 vanilla debian/rules 文件的示例可在 http://arch.debian.org/arch/private/srivasta/ 找到。
大型、复杂的软件包可能有很多您需要处理的错误。如果您直接在源代码中修正了许多错误，并且您不小心，那么区分您应用的各种补丁可能会变得困难。当您必须将软件包更新到集成了部分修复（但不是全部）的新上游版本时，可能会变得非常混乱。您无法获取整套差异（例如，来自 .diff.gz），并找出要作为一个单元撤消哪些补丁集，因为错误已在上游修复。
幸运的是，使用源格式 “3.0 (quilt)”，现在可以将补丁分开保存，而无需修改 debian/rules 以设置补丁系统。补丁存储在 debian/patches/ 中，当解压源代码包时，会自动应用 debian/patches/series 中列出的补丁。顾名思义，可以使用 quilt 管理补丁。
当使用较旧的源 “1.0” 时，也可以分离补丁，但必须使用专用的补丁系统：补丁文件随 Debian 补丁文件 (.diff.gz) 一起提供，通常在 debian/ 目录中。唯一的区别是它们不会立即被 dpkg-source 应用，而是通过依赖于 patch 规则的 debian/rules 的 build 规则应用。相反，它们在 clean 规则中通过依赖于 unpatch 规则来还原。
quilt 是推荐用于此目的的工具。它完成了上述所有操作，并且还允许管理补丁序列。有关更多信息，请参阅 quilt 软件包。
还有其他工具可以管理补丁，例如 dpatch，以及与 cdbs 集成的补丁系统。
单个源代码包通常会构建多个二进制包，以提供同一软件的多个变体（例如，vim 源代码包），或者制作多个小的软件包而不是一个大的软件包（例如，这样用户可以只安装所需的子集，从而节省一些磁盘空间）。
第二种情况可以在 debian/rules 中轻松管理。您只需要将适当的文件从构建目录移动到软件包的临时树中。您可以使用 install 或 debhelper 中的 dh_install 来执行此操作。请务必检查各种软件包的不同排列组合，确保您在 debian/control 中正确设置了软件包间的依赖关系。
第一种情况有点困难，因为它涉及同一软件的多次重新编译，但具有不同的配置选项。vim 源代码包是如何使用手工制作的 debian/rules 文件管理此情况的示例。
以下实践与 debian/control 文件相关。它们补充了 关于软件包描述的策略。
软件包的描述，由 control 文件中相应的字段定义，包含软件包概要和软件包的长描述。第 6.2.1 节，“包描述的通用指南” 描述了软件包描述的两个部分的通用指南。在此之后，第 6.2.2 节，“包概要，或简短描述” 提供了特定于概要的指南，第 6.2.3 节，“长描述” 包含了特定于描述的指南。
软件包描述应为可能使用软件包并从中受益的普通用户编写。例如，开发软件包是为开发者准备的，并且语言可以是技术性的。更通用的应用程序，例如编辑器，应该为不太懂技术的用户编写。
我们对软件包描述的审查使我们得出结论，大多数软件包描述是技术性的，也就是说，不是为非技术用户编写的。除非您的软件包确实仅供技术用户使用，否则这是一个问题。
您如何为非技术用户编写？避免使用术语。避免提及用户可能不熟悉的其他应用程序或框架——GNOME 或 KDE 可以，因为用户可能熟悉这些术语，但 GTK+ 可能不熟悉。尽量不要假设任何知识。如果必须使用技术术语，请介绍它们。
保持客观。软件包描述不是提倡您的软件包的地方，无论您多么喜欢它。请记住，读者可能不关心您关心的相同事物。
对任何其他软件包、协议名称、标准或规范的名称的引用应使用其规范形式（如果存在）。例如，使用 X Window System、X11 或 X；而不是 X Windows、X-Windows 或 X Window。使用 GTK+，而不是 GTK 或 gtk。使用 GNOME，而不是 Gnome。使用 PostScript，而不是 Postscript 或 postscript。
如果您在编写描述时遇到问题，您可以将其发送到 <debian-l10n-english@lists.debian.org> 并请求反馈。
策略规定概要行（简短描述）必须简洁，不重复软件包名称，但也要提供信息。
概要的功能是描述软件包的短语，而不是完整的句子，因此句末标点符号是不合适的：它不需要额外的首字母大写或句末句点（句号）。它还应省略任何初始不定冠词或定冠词——“a”、“an”或“the”。因此，例如
Package: libeg0 Description: exemplification support library
从技术上讲，这是一个名词短语减去冠词，而不是动词短语。一个好的启发式方法是，应该可以将软件包 name 和 synopsis 代入此公式
软件包 name 提供 {a,an,the,some} synopsis。
相关软件包集可以使用另一种方案，该方案将概要分为两部分，第一部分是整个套件的描述，第二部分是软件包在其中的角色摘要
Package: eg-tools Description: simple exemplification system (utilities) Package: eg-doc Description: simple exemplification system - documentation
这些概要遵循修改后的公式。当软件包 “name” 的概要为 “suite (role)” 或 “suite - role” 时，应措辞元素，使其适合公式
软件包 name 为 suite 提供 {a,an,the} role。
长描述是用户在安装软件包之前可获得的主要信息。它应提供用户决定是否安装软件包所需的所有信息。假设用户已经阅读了软件包概要。
长描述应由完整而完整的句子组成。
长描述的第一段应回答以下问题：软件包做什么？它帮助用户完成什么任务？以非技术方式描述这一点很重要，当然，除非软件包的受众必然是技术性的。
以下段落应回答以下问题：为什么我作为用户需要这个软件包？软件包还有哪些其他功能？与其他软件包相比，有哪些突出的功能和缺陷（例如，如果您需要 X，请改用 Y）？此软件包是否以某种方式与其他软件包相关，而软件包管理器未处理（例如，这是 foo 服务器的客户端）？
注意避免拼写和语法错误。确保您进行拼写检查。ispell 和 aspell 都具有用于检查 debian/control 文件的特殊模式
ispell -d american -g debian/control
aspell -d en -D -c debian/control
用户通常希望在软件包描述中回答以下问题
软件包做什么？如果它是另一个软件包的附加组件，那么我们作为附加组件的软件包的简短描述应该放在这里。
我为什么要想要这个软件包？这与上述相关，但并不相同（这是一个邮件用户代理；它很酷、快速，与 PGP 和 LDAP 和 IMAP 接口，具有 X、Y 和 Z 功能）。
如果此软件包不应直接安装，而是由另一个软件包拉入，则应提及这一点。
如果软件包是 experimental，或者有其他原因不应使用它，如果有其他软件包应该代替使用，也应该在这里说明。
此软件包与竞争对手有何不同？它是更好的实现吗？更多功能？不同的功能？我为什么要选择这个软件包。
在 debian/control 中有用于版本控制系统位置的附加字段。
此字段的值应为 http:// URL，指向可 Web 浏览的版本控制系统存储库的副本，该存储库用于维护给定的软件包（如果可用）。
该信息旨在对最终用户有用，他们愿意浏览对软件包完成的最新工作（例如，在查找标记为错误跟踪系统中 pending 的错误的补丁时）。
此字段的值应为字符串，明确标识用于维护给定软件包的版本控制系统存储库的位置（如果可用）。* 标识版本控制系统；当前软件包跟踪系统支持以下系统：arch、bzr (Bazaar)、cvs、darcs、git、hg (Mercurial)、mtn (Monotone)、svn (Subversion)。允许为同一软件包指定不同的 VCS 字段：它们都将显示在 PTS Web 界面中。
该信息旨在对熟悉给定版本控制系统并愿意从 VCS 源代码构建软件包当前版本的用户有用。此信息的其他用途可能包括自动构建给定软件包的最新 VCS 版本。为此，字段指向的位置最好是版本无关的，并指向主分支（对于支持此类概念的 VCS）。此外，最终用户应可以访问指向的位置；满足此要求可能意味着指向存储库的匿名访问，而不是指向同一存储库的 SSH 可访问版本。
在以下示例中，显示了 vim 软件包的 Subversion 存储库的字段实例。请注意 URL 如何采用 svn:// 方案（而不是 svn+ssh://），以及它如何指向 trunk/ 分支。还显示了上面描述的 Vcs-Browser 和 Homepage 字段的用法。
Source: vim Section: editors Priority: optional <snip> Vcs-Svn: svn://svn.debian.org/svn/pkg-vim/trunk/packages/vim Vcs-Browser: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim Homepage: http://www.vim.org
以下实践补充了 关于更新日志文件的策略。
软件包修订的更新日志条目记录该修订中的更改，并且仅记录这些更改。专注于描述自上次版本以来所做的重大和用户可见的更改。
重点关注 什么 被更改了——谁、如何以及何时通常不太重要。话虽如此，请记住礼貌地感谢那些在软件包制作中提供了显著帮助的人（例如，那些发送补丁的人）。
没有必要详细说明琐碎和明显的更改。您也可以将多个更改聚合到一个条目中。另一方面，如果您进行了重大更改，请不要过于简洁。如果存在影响程序行为的更改，请特别清楚。有关更多解释，请使用 README.Debian 文件。
使用通用英语，以便大多数读者可以理解。在解释关闭错误的更改时，避免使用缩写、技术术语和行话，特别是对于由那些没有给您留下特别精通技术的印象的用户提交的错误。要有礼貌，不要咒骂。
有时希望在更新日志条目前缀更改的文件名。但是，没有必要明确列出每个更改的文件，特别是如果更改很小或重复。您可以使用通配符。
当引用错误时，不要假设任何事情。说明问题是什么，如何修复的，并附加 closes: #nnnnn string。有关更多信息，请参阅 第 5.8.4 节，“当新上传关闭错误时”。
更新日志条目不应记录通用打包问题（嘿，如果您正在寻找 foo.conf，它在 /etc/blah/ 中。），因为管理员和用户应该至少大致了解此类事情在 Debian 系统上通常是如何安排的。但是，如果您更改了配置文件的位置，请提及。
只有在同一软件包修订中实际修复的错误才应该用更新日志条目关闭。在更新日志中关闭无关的错误是不好的做法。请参阅 第 5.8.4 节，“当新上传关闭错误时”。
更新日志条目不应用于与错误报告者的随意讨论（当我使用选项 bar 启动 foo 时，我看不到段错误；发送更多信息）、关于生活、宇宙和一切事物的概括性陈述（抱歉这次上传花了这么长时间，但我得了流感），或请求帮助（此软件包的错误列表很大，请帮我一把）。此类事情通常不会被目标受众注意到，但可能会惹恼那些希望阅读有关软件包实际更改信息的人。有关如何使用错误跟踪系统的更多信息，请参阅 第 5.8.2 节，“回复错误”。
在适当的维护者上传的第一个更新日志条目中承认非维护者上传中修复的错误是一种古老的传统。由于我们现在有版本跟踪，因此保留 NMUed 更新日志条目并在您自己的更新日志条目中提及此事实就足够了。
以下示例演示了更新日志条目中的一些常见错误或不良风格示例。
* Fixed all outstanding bugs.
显然，这没有告诉读者任何有用的信息。
* Applied patch from Jane Random.
补丁是关于什么的？
* Late night install target overhaul.
大修完成了什么？提及深夜是想提醒我们不应该信任该代码吗？
* Fix vsync FU w/ ancient CRTs.
缩写词太多，而且不太清楚 fsckup（哎呀，一个脏话！）实际上是关于什么的，或者它是如何修复的。
* This is not a bug, closes: #nnnnnn.
首先，绝对没有必要上传软件包来传达此信息；相反，请使用错误跟踪系统。其次，没有解释为什么该报告不是错误。
* Has been fixed for ages, but I forgot to close; closes: #54321.
如果由于某种原因您在前一个更新日志条目中没有提及错误编号，那没问题，只需在 BTS 中正常关闭错误即可。无需触碰更新日志文件，假设修复的描述已经在其中（这也适用于上游作者/维护者的修复，您不必跟踪他们很久以前在您的更新日志中修复的错误）。
* Closes: #12345, #12346, #15432
描述在哪里？如果您想不出描述性消息，请从插入每个不同错误的标题开始。
关于软件包更改的重要新闻也可以放在 NEWS.Debian 文件中。新闻将由 apt-listchanges 等工具显示，在所有其他更新日志之前。这是让用户了解软件包重大更改的首选方式。它比使用 debconf 注释更好，因为它不那么烦人，并且用户可以在安装后返回并参考 NEWS.Debian 文件。它比在 README.Debian 中列出主要更改更好，因为用户很容易错过此类注释。
文件格式与 debian 更新日志文件相同，但省略星号，并在必要时用完整的段落而不是更简洁的摘要来描述每个新闻项，这些摘要将放入更新日志中。最好通过 dpkg-parsechangelog 运行您的文件以检查其格式，因为它不会像更新日志那样在构建期间自动检查。以下是真实 NEWS.Debian 文件的示例
cron (3.0pl1-74) unstable; urgency=low
The checksecurity script is no longer included with the cron package:
it now has its own package, checksecurity. If you liked the
functionality provided with that script, please install the new
package.
-- Steve Greenland <stevegr@debian.org> Sat, 6 Sep 2003 17:15:03 -0500
NEWS.Debian 文件安装为 /usr/share/doc/。它是压缩的，并且始终具有该名称，即使在 Debian 原生软件包中也是如此。如果您使用 package/NEWS.Debian.gzdebhelper，dh_installchangelogs 将为您安装 debian/NEWS 文件。
与更新日志文件不同，您无需在每次发布时都更新 NEWS.Debian 文件。仅当您有用户应该知道的特别有新闻价值的内容时才更新它们。如果您根本没有新闻，则无需在您的软件包中附带 NEWS.Debian 文件。没有消息就是好消息！
维护者脚本包括文件 debian/postinst、debian/preinst、debian/prerm 和 debian/postrm。这些脚本负责任何软件包安装或卸载设置，这些设置不仅仅通过创建或删除文件和目录来处理。以下说明补充了 Debian 策略。
维护者脚本必须是幂等的。这意味着您需要确保如果脚本被调用两次，而通常只调用一次，则不会发生任何不好的事情。
标准输入和输出可能会被重定向（例如，进入管道）以用于日志记录目的，因此不要依赖它们是 tty。
所有提示或交互式配置都应保持在最低限度。当需要时，您应该使用 debconf 软件包作为界面。请记住，在任何情况下，提示都只能在 postinst 脚本的 configure 阶段进行。
使维护者脚本尽可能简单。我们建议您使用纯 POSIX shell 脚本。请记住，如果您确实需要任何 bash 功能，维护者脚本必须具有 bash shebang 行。POSIX shell 或 Bash 优先于 Perl，因为它们使 debhelper 能够轻松地向脚本添加位。
如果您更改了维护者脚本，请务必测试软件包删除、双重安装和清除。确保已清除的软件包已完全消失，也就是说，它必须删除在任何维护者脚本中直接或间接创建的任何文件。
如果您需要检查命令是否存在，您应该使用类似以下的代码
if [ -x /usr/sbin/install-docs ]; then ...
如果您不想在维护者脚本中硬编码命令的路径，以下符合 POSIX 标准的 shell 函数可能会有所帮助
pathfind() {
OLDIFS="$IFS"
IFS=:
for p in $PATH; do
if [ -x "$p/$*" ]; then
IFS="$OLDIFS"
return 0
fi
done
IFS="$OLDIFS"
return 1
}您可以使用此函数在 $PATH 中搜索命令名称，该命令名称作为参数传递。如果找到命令，则返回 true（零），否则返回 false。这确实是最便携的方式，因为 command -v、type 和 which 不是 POSIX 标准。
虽然 which 是一个可以接受的替代方案，因为它来自必需的 debianutils 软件包，但它不在根分区上。也就是说，它在 /usr/bin 中而不是 /bin 中，因此在 /usr 分区挂载之前运行的脚本中不能使用它。但是，大多数脚本不会有这个问题。
Debconf 是一个配置管理系统，各种打包脚本（主要是 postinst）可以使用它来请求用户反馈，以了解如何配置软件包。现在必须避免直接用户交互，而倾向于使用 debconf 交互。这将使未来的非交互式安装成为可能。
Debconf 是一个很棒的工具，但经常被滥用。许多常见错误在 debconf-devel(7) 手册页中列出。如果您决定使用 debconf，这是您必须阅读的内容。此外，我们在此处记录了一些最佳实践。
这些指南包括一些写作风格和排版建议、关于 debconf 用法的通用注意事项以及对发行版的某些部分（例如安装系统）的更具体建议。
自从 debconf 出现在 Debian 中以来，它已被广泛滥用，并且 Debian 发行版收到的几项批评来自 debconf 滥用，需要回答大量问题才能安装任何小东西。
将使用说明保留在它们所属的位置：NEWS.Debian 或 README.Debian 文件。仅将注释用于可能直接影响软件包可用性的重要注释。请记住，注释始终会阻止安装，直到确认或通过电子邮件打扰用户。
仔细选择维护者脚本中问题的优先级。有关优先级的详细信息，请参阅 debconf-devel(7)。大多数问题应使用中等和低优先级。
大多数 Debian 软件包维护者不是以英语为母语的人。因此，对他们来说，编写措辞正确的模板可能并不容易。
请使用（并滥用）<debian-l10n-english@lists.debian.org> 邮件列表。让您的模板经过校对。
写得不好的模板会给您的软件包、您的工作……甚至 Debian 本身带来糟糕的印象。
尽可能避免使用技术术语。如果某些术语对您来说听起来很常见，那么对于其他人来说可能无法理解。如果您无法避免它们，请尝试解释它们（使用扩展描述）。这样做时，请尝试在冗长和简洁之间取得平衡。
Debconf 模板可以翻译。Debconf 及其姊妹软件包 po-debconf 提供了一个简单的框架，用于让翻译团队甚至个人翻译模板。
请使用基于 gettext 的模板。在您的开发系统上安装 po-debconf 并阅读其文档（man po-debconf 是一个好的开始）。
避免过于频繁地更改模板。更改模板文本会给翻译人员带来更多工作，这将使他们的翻译变得模糊。模糊翻译是一个字符串，其原始字符串自翻译以来已更改，因此需要翻译人员进行一些更新才能使用。当更改足够小时，原始翻译会保留在 PO 文件中，但标记为 fuzzy。
如果您计划对原始模板进行更改，请使用 po-debconf 软件包提供的通知系统，即 podebconf-report-po，来联系翻译人员。大多数活跃的翻译人员反应非常迅速，将他们的工作与您修改后的模板一起包含在内将为您节省额外的上传。如果您使用基于 gettext 的模板，翻译人员的姓名和电子邮件地址会在 PO 文件标头中提及，并且将被 podebconf-report-po 使用。
推荐使用该实用程序的方法是
cd debian/po && podebconf-report-po --call --languageteam --withtranslators --deadline="+10 days"
此命令将首先同步 debian/po 目录中的 PO 和 POT 文件，同步对象为 debian/po/POTFILES.in 中列出的模板文件。然后，它将向 <debian-i18n@lists.debian.org> 邮件列表发送新的翻译请求。最后，它还将向语言团队（在每个 PO 文件的 Language-Team 字段中提及）以及最后一位翻译者（在 Last-translator 中提及）发送翻译更新请求。
为译者设定截止日期总是受欢迎的，这样他们可以安排自己的工作。请记住，一些翻译团队有正式的翻译/审校流程，低于 10 天的延迟被认为是不合理的。更短的延迟会给翻译团队带来过大的压力，应仅用于非常小的更改。
如有疑问，您也可以联系给定语言的翻译团队 (debian-l10n-xxxxx@lists.debian.org) 或 <debian-i18n@lists.debian.org> 邮件列表。
当 debconf 模板的文本被更正，并且您 确信 该更改 不 影响翻译时，请善待译者并取消他们的翻译的模糊标记。
如果您不这样做，只要译者发送更新，整个模板就不会被翻译。
要取消翻译的模糊标记，您可以使用 msguntypot 命令（po4a 软件包的一部分）。
重新生成 POT 和 PO 文件。
debconf-updatepo
制作 POT 文件的副本。
cp templates.pot templates.pot.orig
制作所有 PO 文件的副本。
mkdir po_fridge; cp *.po po_fridge
更改 debconf 模板文件以修复错别字。
（再次）重新生成 POT 和 PO 文件。
debconf-updatepo
此时，错别字修复使所有翻译都带有模糊标记，而这个不幸的更改是您的主目录中的 PO 文件与冰箱中的 PO 文件之间唯一的区别。以下是如何解决此问题。
丢弃模糊翻译，恢复冰箱中的翻译。
cp po_fridge/*.po .
手动将 PO 文件与新的 POT 文件合并，但要考虑到无用的模糊标记。
msguntypot -o templates.pot.orig -n templates.pot *.po
清理。
rm -rf templates.pot.orig po_fridge
模板文本不应引用属于某些 debconf 界面的小部件。诸如 如果您回答“是”... 之类的句子对于使用复选框进行布尔值问题的图形界面用户来说毫无意义。
字符串模板的描述也应避免提及默认值。首先，因为这与用户看到的值是冗余的。其次，因为这些默认值可能与维护者选择的不同（例如，当 debconf 数据库被预先设定时）。
更一般地说，尽量避免提及用户操作。只需给出事实。
您应该避免使用第一人称（我将这样做... 或 我们建议...）。计算机不是人，Debconf 模板不代表 Debian 开发人员发言。您应该使用中性的结构。那些已经撰写过科学出版物的人，只需像撰写科学论文一样编写您的模板。但是，如果仍然可能，请尝试使用主动语态，例如 如果...，则启用此项 而不是 如果...，则可以启用此项。
本部分提供了一些信息，这些信息主要来自 debconf-devel(7) 手册页。
从多个值中选择一个值。选项必须在名为“Choices”的字段中指定。用逗号和空格分隔可能的值，例如：Choices: yes, no, maybe。
如果选项是可翻译的字符串，则可以使用 __Choices 将“Choices”字段标记为可翻译的。双下划线将把每个选项拆分为单独的字符串。
po-debconf 系统还提供了仅将 某些 选项标记为可翻译的有趣可能性。示例
Template: foo/bar Type: Select #flag:translate:3 __Choices: PAL, SECAM, Other _Description: TV standard: Please choose the TV standard used in your country.
在该示例中，只有“Other”字符串是可翻译的，而其他字符串是不应翻译的首字母缩略词。以上内容仅允许将“Other”包含在 PO 和 POT 文件中。
debconf 模板标志系统提供了许多这样的可能性。po-debconf(7) 手册页列出了所有这些可能性。
与其说是一个问题本身，不如说此数据类型表示可以向用户显示的注释。它应该仅用于用户确实应该看到的重要注释，因为 debconf 会尽力确保用户看到它；暂停安装，让用户按下一个键，甚至在某些情况下将注释邮寄给他们。
模板描述分为两个部分：短描述和长描述。短描述位于模板的 Description: 行中。
短描述应保持简短（50 个字符左右），以便大多数 debconf 界面可以容纳它。保持简短也有助于翻译人员，因为通常翻译最终会比原文更长。
短描述应该能够独立存在。某些界面默认情况下不显示长描述，或者仅在用户明确要求时显示，甚至根本不显示。避免诸如“您想做什么？”之类的内容。
短描述不一定必须是一个完整的句子。这是保持简短高效建议的一部分。
长描述不应逐字重复短描述。如果您想不出长描述，那么首先，请多思考一下。发布到 debian-devel。寻求帮助。参加写作课！长描述很重要。如果在做了所有这些之后，您仍然想不出任何东西，请将其留空。
长描述应使用完整的句子。段落应保持简短以提高可读性。不要在同一段落中混合两个想法，而是使用另一个段落。
不要太冗长。用户倾向于忽略太长的屏幕。根据经验，20 行是一个您不应超过的界限，因为这意味着在经典的对话框界面中，人们需要滚动，而很多人根本不会这样做。
长描述绝不应包含问题。
对于取决于模板类型（字符串、布尔值等）的具体规则，请阅读下文。
以下是根据模板类型正确编写 Description（短描述和长描述）的具体说明。
短描述是提示，不是标题。避免问题风格的提示（IP 地址？）而倾向于开放式提示（IP 地址：）。建议使用冒号。
长描述是对短描述的补充。在长描述部分，解释正在询问什么，而不是使用更长的词语再次询问相同的问题。使用完整的句子。强烈反对简洁的写作风格。
短描述应以问题的形式措辞，该问题应保持简短，并且通常应以问号结尾。如果问题相当长，则允许甚至鼓励简洁的写作风格（请记住，翻译通常比原始版本更长）。
再次，请避免引用特定的界面小部件。此类模板的一个常见错误是“如果您回答是”类型的结构。
短描述是提示，不是标题。 不要 使用无用的“请选择...”结构。用户足够聪明，可以弄清楚他们必须选择一些东西...:)
长描述将完成短描述。它可以引用可用选项。它也可能提及用户可以选择多个可用选项，如果模板是多选模板（尽管界面通常会明确这一点）。
如果 select 模板的默认值可能因用户语言而异（例如，如果选项是语言选择），请使用 _Default 技巧。
此特殊字段允许翻译人员根据自己的语言放置最合适的选项。当使用他们的语言时，它将成为默认选项，而当使用英语时，将使用您自己的提到的 Default Choice。
示例，取自 geneweb 软件包模板
Template: geneweb/lang Type: select __Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv) # This is the default choice. Translators may put their own language here # instead of the default. # WARNING : you MUST use the ENGLISH NAME of your language # For instance, the french translator will need to put French (fr) here. _Default: English[ translators, please see comment in PO files] _Description: Geneweb default language:
请注意括号的使用，它允许在 debconf 字段中使用内部注释。另请注意注释的使用，这些注释将显示在翻译人员将要处理的文件中。
注释是必要的，因为 _Default 技巧有点令人困惑：翻译人员可能会放置他们自己的选择
请勿使用空默认值字段。如果您不想使用默认值，请完全不要使用 Default。
如果您使用 po-debconf（并且您应该这样做，请参阅第 6.5.2.2 节，“善待译者”），如果您认为此字段可以翻译，请考虑使其可翻译。
如果默认值可能因语言/国家/地区而异（例如，语言选择的默认值），请考虑使用 po-debconf(7) 中记录的特殊 _Default 类型。
本节包含供开发人员使用的全局信息，以使翻译人员的生活更轻松。有关国际化的更多信息，以及对国际化感兴趣的开发人员和翻译人员的信息，请参见 Debian 中的国际化和本地化 文档。
与移植者一样，翻译人员也承担着艰巨的任务。他们处理许多软件包，并且必须与许多不同的维护者协作。此外，在大多数情况下，他们的母语不是英语，因此您可能需要对他们特别耐心。
debconf 的目标是使软件包配置对维护者和用户来说都更加容易。最初，debconf 模板的翻译是通过 debconf-mergetemplate 处理的。但是，该技术现在已被弃用；完成 debconf 国际化的最佳方法是使用 po-debconf 软件包。这种方法对维护者和翻译人员都更简单；提供了过渡脚本。
使用 po-debconf，翻译存储在 .po 文件中（借鉴 gettext 翻译技术）。特殊的模板文件包含原始消息并标记哪些字段是可翻译的。当您通过调用 debconf-updatepo 更改可翻译字段的值时，翻译将被标记为需要翻译人员注意。然后，在构建时，dh_installdebconf 程序会处理所有必要的魔法，以将模板以及最新的翻译添加到二进制软件包中。有关详细信息，请参阅 po-debconf(7) 手册页。
文档国际化对于用户至关重要，但需要大量劳动。没有办法消除所有这些工作，但是您可以使翻译人员的工作更轻松。
如果您维护任何规模的文档，如果翻译人员可以访问源代码控制系统，则对他们来说会更容易。这使翻译人员可以看到两个版本的文档之间的差异，因此，例如，他们可以看到哪些内容需要重新翻译。建议翻译的文档维护一个关于翻译所基于的源代码控制修订版本的注释。 debian-installer 软件包中的 doc-check 提供了一个有趣的系统，该系统使用结构化注释显示任何给定语言的翻译状态概述，用于要翻译的文件的当前修订版本，以及用于翻译文件的翻译所基于的原始文件的修订版本。您可能希望在您的 VCS 区域中调整并提供该系统。
如果您维护 XML 或 SGML 文档，我们建议您隔离任何与语言无关的信息，并将这些信息定义为单独文件中的实体，该文件由所有不同的翻译包含。例如，这使得跨多个文件保持 URL 最新变得更加容易。
一些工具（例如 po4a、poxml 或 translate-toolkit）专门用于从不同格式中提取可翻译的材料。它们生成 PO 文件，这是一种翻译人员非常常见的格式，它允许在翻译文档更新时查看哪些内容需要重新翻译。
保持 autoconf 的 config.sub 和 config.guess 文件最新对于移植者至关重要，尤其是在更易变的架构上。来自 autotools-dev 软件包的 /usr/share/doc/autotools-dev/README.Debian.gz 文件中，已经综合了任何使用 autoconf 和/或 automake 的软件包的一些非常好的打包实践。强烈建议您阅读此文件并遵循给定的建议。
库总是很难打包，原因有很多。策略施加了许多约束，以简化其维护并确保在新上游版本发布时升级尽可能简单。库中的破坏可能会导致数十个依赖软件包崩溃。
库软件包的良好实践已在 库软件包指南 中进行了分组。
请务必遵循 关于文档的策略。
如果您的软件包包含从 XML 或 SGML 构建的文档，我们建议您不要在二进制软件包中发布 XML 或 SGML 源代码。如果用户想要文档的源代码，他们应该检索源代码包。
策略规定文档应以 HTML 格式发布。如果方便且可以输出合理的质量，我们还建议以 PDF 和纯文本格式发布文档。但是，通常不适合发布其源格式为 HTML 的文档的纯文本版本。
主要发布的的手册应在安装时在 doc-base 中注册自己。有关更多信息，请参见 doc-base 软件包文档。
Debian 策略（第 12.1 节）指示每个程序、实用程序和函数都应附带手册页，并建议其他对象（如配置文件）也应附带手册页。如果您正在打包的工作没有这样的手册页，请考虑编写它们以包含在您的软件包中，并将其提交给上游。
手册页不需要直接以 troff 格式编写。流行的源格式是 Docbook、POD 和 reST，可以使用 xsltproc、pod2man 和 rst2man 分别进行转换。在较小程度上，help2man 程序也可以用于编写存根。
几种特定类型的软件包具有特殊的子策略以及相应的打包规则和实践
Perl 相关软件包具有 Perl 策略，遵循该策略的一些软件包示例是 libdbd-pg-perl（二进制 perl 模块）或 libmldbm-perl（架构独立的 perl 模块）。
Python 相关软件包具有其 python 策略；请参阅 python 软件包中的 /usr/share/doc/python/python-policy.txt.gz。
Emacs 相关软件包具有 emacs 策略。
Java 相关软件包具有其 java 策略。
Ocaml 相关软件包具有自己的策略，可在 ocaml 软件包的 /usr/share/doc/ocaml/ocaml_packaging_policy.gz 中找到。一个很好的例子是 camlzip 源代码包。
提供 XML 或 SGML DTD 的软件包应符合 sgml-base-doc 软件包中找到的建议。
Lisp 软件包应在 common-lisp-controller 中注册自己，有关该信息，请参阅 /usr/share/doc/common-lisp-controller/README.packaging。
将大量架构无关的数据与程序一起打包是很常见的。例如，音频文件、图标集合、壁纸图案或其他图形文件。如果此数据的大小与软件包其余部分的大小相比可以忽略不计，那么最好将所有数据都放在一个软件包中。
但是，如果数据的大小相当大，请考虑将其拆分到单独的架构无关软件包 (_all.deb) 中。通过这样做，您可以避免在十一个或更多 .deb 中不必要地重复相同的数据，每个架构一个 .deb。虽然这会在 Packages 文件中增加一些额外的开销，但可以节省 Debian 镜像上的大量磁盘空间。分离架构无关的数据还可以减少在整个 Debian 存档上运行时 lintian 的处理时间（请参阅 第 A.2 节，“软件包检查工具”）。
如果您在构建期间需要特定的语言环境，您可以通过以下技巧创建一个临时文件
如果您将 LOCPATH 设置为等效于 /usr/lib/locale 的值，并将 LC_ALL 设置为您生成的语言环境的名称，您应该可以在不成为 root 用户的情况下获得您想要的结果。类似这样
LOCALE_PATH=debian/tmpdir/usr/lib/locale LOCALE_NAME=en_IN LOCALE_CHARSET=UTF-8 mkdir -p $LOCALE_PATH localedef -i $LOCALE_NAME.$LOCALE_CHARSET -f $LOCALE_CHARSET $LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET # Using the locale LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date
Deborphan 是一个帮助用户检测哪些软件包可以从系统中安全删除的程序，即那些没有软件包依赖于它们的软件包。默认操作是仅在 libs 和 oldlibs 部分中搜索，以查找未使用的库。但是，当传递正确的参数时，它会尝试捕获其他无用的软件包。
例如，使用 --guess-dummy，deborphan 尝试搜索所有过渡软件包，这些软件包是升级所必需的，但现在可以安全删除。为此，它会在它们的简短描述中查找字符串 dummy 或 transitional。
因此，当您创建这样的软件包时，请确保将此文本添加到您的简短描述中。如果您正在寻找示例，只需运行：apt-cache search .|grep dummy 或 apt-cache search .|grep transitional。
此外，建议将其 section 调整为 oldlibs，将其 priority 调整为 extra，以便于 deborphan 的工作。
原始源代码 tarball 有两种：纯净源代码和重新打包的上游源代码。
纯净源代码 tarball 的定义特征是 .orig.tar.{gz,bz2,xz} 文件与上游作者正式发布的 tarball 字节对字节完全相同。[5] 这使得可以使用校验和轻松验证 Debian 版本和上游版本之间的所有更改都包含在 Debian diff 中。此外，如果原始源代码很大，则已经拥有上游 tarball 的上游作者和其他人如果想详细检查您的打包，则可以节省下载时间。
关于上游作者在他们的 tarball 内遵循的目录结构，没有普遍接受的指南，但 dpkg-source 仍然能够将大多数上游 tarball 作为纯净源代码处理。它的策略等同于以下内容
它通过执行以下操作在空的临时目录中解压缩 tarball
zcat path/to/packagename_upstream-version.orig.tar.gz | tar xf -
如果在此之后，临时目录仅包含一个目录而没有其他文件，则 dpkg-source 将该目录重命名为 packagename-upstream-version(.orig)
否则，上游 tarball 必须在没有公共顶级目录的情况下打包（上游作者真可耻！）。在这种情况下，dpkg-source 将临时目录本身重命名为 packagename-upstream-version(.orig)
如果可能，您应该上传带有纯净源代码 tarball 的软件包，但是由于各种原因，这可能是不可能的。如果上游根本不以 gzipped tar 形式分发源代码，或者如果上游的 tarball 包含您必须在上传之前删除的非 DFSG 自由材料，则属于这种情况。
在这些情况下，开发人员必须自己构建合适的 .orig.tar.{gz,bz2,xz} 文件。我们将这样的 tarball 称为重新打包的上游源代码。请注意，重新打包的上游源代码与 Debian 原生软件包不同。重新打包的源代码仍然带有 Debian 特定的更改，这些更改位于单独的 .diff.gz 或 .debian.tar.{gz,bz2,xz} 中，并且仍然具有由 upstream-version 和 debian-version 组成的版本号。
在某些情况下，即使上游分发了原则上可以以纯净形式使用的 .tar.{gz,bz2,xz}，也可能需要重新打包源代码。最明显的情况是，如果通过重新压缩 tar 存档或从上游存档中删除真正无用的垃圾，可以实现 显著的 空间节省。在这里使用您自己的判断力，但如果您重新打包了本来可以是纯净的源代码，请准备好为您的决定辩护。
重新打包的 .orig.tar.{gz,bz2,xz}
应该在生成的源代码包中记录。有关如何获得重新打包的源代码以及如何重现它的详细信息应在 debian/copyright 中提供。在您的 debian/rules 文件中提供一个 get-orig-source 目标也是一个好主意，该目标重复该过程，如策略手册 主构建脚本：debian/rules 中所述。
不应该包含任何不来自上游作者的文件，或其内容已被您更改的文件。[6]
应该，除非由于法律原因不可能，否则应保留上游作者提供的所有构建和可移植性基础设施。 例如，仅仅因为一个文件仅在 MS-DOS 上构建时使用，就省略该文件不是充分的理由。 同样，即使您的 debian/rules 所做的第一件事是通过运行配置脚本来覆盖它，也不应省略上游提供的 Makefile。
(理由： 对于需要在非 Debian 平台上构建软件的 Debian 用户来说，从 Debian 镜像站点获取源代码而不是尝试查找规范的上游分发点是很常见的做法)。
应该 使用 packagename-upstream-version.orig
应该 使用最大压缩率进行 gzip 或 bzip2 压缩。
调试包是名称以 -dbg 结尾的软件包，其中包含 gdb 可以使用的附加信息。 由于 Debian 二进制文件默认情况下会被剥离符号信息，因此在 Debian 二进制文件上运行 gdb 时，调试信息（包括函数名称和行号）通常不可用。 调试包允许需要此附加调试信息的用户安装它，而不会用这些信息臃肿常规系统。
是否创建调试包取决于软件包的维护者。 鼓励维护者为库软件包创建调试包，因为这可以帮助调试许多链接到该库的程序。 一般来说，不必为所有程序都添加调试包； 这样做会使存档文件过于臃肿。 但是，如果维护者发现用户经常需要程序的调试版本，那么为该程序制作调试包可能是值得的。 诸如 apache 和 X 服务器之类的核心基础设施程序也是调试包的良好候选对象。
一些调试包可能包含库或其他二进制文件的完整特殊调试构建版本，但大多数调试包可以通过包含分离的调试符号来节省空间和构建时间，gdb 可以在调试程序或库时动态查找和加载这些符号。 Debian 中的约定是将这些符号保存在 /usr/lib/debug/ 中，其中 pathpath 是可执行文件或库的路径。 例如，/usr/bin/foo 的调试符号放在 /usr/lib/debug/usr/bin/foo 中，/usr/lib/libfoo.so.1 的调试符号放在 /usr/lib/debug/usr/lib/libfoo.so.1 中。
可以使用 objcopy --only-keep-debug 从目标文件中提取调试符号。 然后可以剥离目标文件，并使用 objcopy --add-gnu-debuglink 来指定调试符号文件的路径。 objcopy(1) 详细解释了这是如何工作的。
debhelper 中的 dh_strip 命令支持创建调试包，并且可以负责使用 objcopy 为您分离出调试符号。 如果您的软件包使用 debhelper，您只需调用 dh_strip --dbg-package=libfoo-dbg，并在 debian/control 中为调试包添加一个条目。
请注意，调试包应依赖于它为其提供调试符号的软件包，并且此依赖项应进行版本控制。 例如
Depends: libfoo (= ${binary:Version})
元软件包是一个主要为空的软件包，它可以轻松安装一组连贯的软件包，这些软件包可以随着时间推移而发展。 它通过依赖于该组中的所有软件包来实现这一点。 感谢 APT 的强大功能，元软件包维护者可以调整依赖项，用户的系统将自动获取补充软件包。 自动安装的已删除软件包也将被标记为删除候选对象（甚至会被 aptitude 自动删除）。 gnome 和 linux-image-amd64 是元软件包的两个示例（由源软件包 meta-gnome2 和 linux-latest 构建）。
元软件包的长描述必须清楚地记录其用途，以便用户知道如果删除该软件包会丢失什么。 建议明确说明后果。 这对于在初始安装期间安装且用户未明确安装的元软件包尤其重要。 这些软件包往往对于确保系统平滑升级非常重要，应劝阻用户卸载它们以避免潜在的损坏。
[5] 我们无法阻止上游作者更改他们分发的 tarball 而不增加版本号，因此无法保证原始 tarball 与上游当前在任何时间点分发的内容完全相同。 所有可以期望的是它与上游曾经确实分发过的某些内容相同。 如果稍后出现差异（例如，如果上游注意到他在原始分发中没有使用最大压缩率，然后重新 gzip 它），那就太糟糕了。 由于没有好的方法为同一版本上传新的 .orig.tar.{gz,bz2,xz}，因此甚至没有必要将这种情况视为错误。
[6] 作为特殊例外，如果省略非自由文件会导致源代码在没有 Debian diff 的帮助下无法构建，那么可以考虑编辑这些文件，仅省略其中的非自由部分，和/或在源代码树根目录的 README.source 文件中解释情况。 但在这种情况下，请同时敦促上游作者使非自由组件更容易与源代码的其余部分分离。