Debian 新维护人员手册 --------------------------------------------------------------------- Josip Rodin 原始内容  Osamu Aoki 更新内容  Aron Xu   李凌   郑原真   版本 1.2.32-svn --------------------------------------------------------------------- 版权 © 1998-2002 Josip Rodin 版权 © 2005-2011 Osamu Aoki 版权 © 2010 Craig Small 版权 © 2010 Raphaël Hertzog     本文档可在 GNU 通用公共许可证第二版或更高版本的条款规定下使用。     This document was made using these two documents as examples: * Making a Debian Package (AKA the Debmake Manual), copyright © 1997 Jaldhar Vyas.     * The New-Maintainer's Debian Packaging Howto, copyright © 1997 Will Lowe. 2013-05-02 16:38:20 UTC --------------------------------------------------------------------- 目录 1. 从一条正确的路开始 1.1. Debian 的社会驱动力 1.2. 开发时需要的软件 1.3. Documentation needed for development 1.4. 到何处寻求帮助 2. 第一步 2.1. Debian package building workflow 2.2. 选择你的程序 2.3. 获得程序，并且试用它 2.4. Simple build systems 2.5. Popular portable build systems 2.6. 软件包名称和版本 2.7. Setting up dh_make 2.8. Initial non-native Debian package 2.9. Initial native Debian package 3. 修改源代码 3.1. Setting up quilt 3.2. Fixing upstream bugs 3.3. Installation of files to their destination 3.4. 不一样的库名称 4. debian 目录中的必须内容 4.1. control 4.2. copyright 4.3. changelog 4.4. rules 4.4.1. Targets of the rules file 4.4.2. 默认的 rules 文件 4.4.3. 定制 rules 文件 5. debian 目录下的其他文件 5.1. README.Debian 5.2. compat 5.3. conffiles 5.4. package.cron.* 5.5. dirs 5.6. package.doc-base 5.7. docs 5.8. emacsen-* 5.9. package.examples 5.10. package.init and package.default 5.11. install 5.12. package.info 5.13. package.links 5.14. {package.,source/}lintian-overrides 5.15. manpage.* 5.15.1. manpage.1.ex 5.15.2. manpage.sgml.ex 5.15.3. manpage.xml.ex 5.16. package.manpages 5.17. menu 5.18. NEWS 5.19. {pre,post}{inst,rm} 5.20. package.symbols 5.21. TODO 5.22. watch 5.23. source/format 5.24. source/local-options 5.25. source/options 5.26. patches/* 6. 构建软件包 6.1. 完整的(重)构建 6.2. 自动编译系统 6.3. debuild 命令 6.4. pbuilder 软件包 6.5. git-buildpackage 和相似命令 6.6. 快速重构建 7. 检查软件包中的错误 7.1. Suspicious changes 7.2. Verifying a package's installation 7.3. Verifying a package's maintainer scripts 7.4. Using lintian 7.5. The debc command 7.6. The debdiff command 7.7. The interdiff command 7.8. The mc command 8. 上传软件包 8.1. 上传到 Debian 仓库 8.2. 在上传时包含 orig.tar.gz 文件 8.3. 跳过的上传 9. 更新软件包 9.1. 新的 Debian 版本 9.2. 检查新上游版本 9.3. 新上游版本 9.4. 更新打包风格 9.5. UTF-8 conversion 9.6. 对更新软件包的几点提示 A. Advanced packaging A.1. Shared libraries A.2. Managing debian/package.symbols A.3. Multiarch A.4. Building a shared library package 第 1 章 从一条正确的路开始 这篇文档试图为普通 Debian 用户，和希望对 Debian 软件包有所了解的     开发人员讲述如何制作 Debian 软件包。在这里，我们尽可能使用通俗的 语言，并辅以大量实例来直观地展示每一个细节。正如一句古罗马谚语说 得好：一例胜千言！     本文档已经针对 Debian squeeze 进行了更新。^[1] Debian 的软件包系统是使它跻身顶级发行版行列的重要原因之一。尽管已 经有相当数量的软件被打包成 Debian 的格式，但有时还是需要安装一些 不是这一格式的软件。可能你正为如何制作自己的软件包而感到迷惑，也     可能正认为这么做很难。如果你是一个刚刚接触 Debian 的初学者，那么 是的，它的确很难；不过假如你真的只是一个初入此门的新手，现在大概 也不会来读这篇文档了。:-) 你的确需要对 Unix 编程有所了解，但显然 没必要是这方面的天才。^[2] 对于 Debian 软件包维护人员来说，有一件事是非常明确的：创建并维护     一个 Debian 软件包需要花费很多精力，所需的时间很可能远不只是几个 小时。维护人员需要有良好的技术基础，同时也需要十分勤奋，这样才能 保证我们的系统正常运行而不出现问题。     如果你在打包方面需要别人帮助，请阅读第 1.4 节 “到何处寻求帮助”。 本文的最新版随时都可以在 http://www.debian.org/doc/maint-guide/ (http://www.debian.org/doc/maint-guide/) 上和 maint-guide 软件包     里找到。文档的简体中文翻译可以在 maint-guide-zh-cn 软件包里找到。 还有一点需要注意的是，这篇文档的内容相对于当前的开发情况可能会有 略微的延迟。 由于这篇文档是一份手把手的教程，所以在一些重要的话题上会对每个步     骤都做详细的解释。因而你可能觉得它们之中有一些与你的想法毫不相干 。请准备好足够的耐心来学习。同时我也有意地省略了某些不必要的细节 ，以使这篇文档尽可能保持简洁。 1.1. Debian 的社会驱动力     以下是一些有关 Debian 的社会动力学报告，希望它们有助于你掌握如何 与 Debian 项目进行互动的方法。 * 我们都是志愿者。 o 任何人都不能把事情强加给他人。 o 你应该主动地做自己的事情。 * 友好合作是我们前行的动力。 o 你的贡献不应致使他人过劳。 o 只有当别人欣赏你的贡献时，它才真正有价值。     * Debian 不是一所学校，没有老师会自动地注意你。 o 你需要有自学大量知识的能力。 o 其他志愿者的注意是非常稀缺的资源。 * Debian 在不断进步。 o Debian 期望你制作出高质量的软件包。 o 你应该适时改变自己来适应变化。     在 Debian 社区中有几个常见的角色。 * Upstream author (上游作者)：程序的原始作者。 * Upstream maintainer (上游维护者)：目前在上游维护程序代码的人 。 * Maintainer (软件包维护者)：制作并维护该程序的 Debian 软件包的 人。     * Sponsor (保证人)：检查内容后帮助维护者上传软件包到 Debian 官 方仓库的人。 * Mentor (指导者)：帮助维护者熟悉和深入打包的人。 * Debian Developer (DD)：Debian 社区的官方成员。DD 拥有向 Debian 官方仓库上传的全部权限。 * Debian Maintainer (DM)：拥有对 Debian 官方仓库部分上传权限的 人。 注意，你不可能在一夜之间成为 Debian Developer，因为成为 DD 所需要     的远不只是技术技巧。别因此气馁，如果你的软件包对其他人有用，你可 以作为软件包的 Maintainer，通过一位 Sponsor 来上传它，或者申请成 为 Debian Maintainer。 还有，要成为 Debian Developer 不一定要创建新软件包。对已有软件做     出贡献也是成为 Debian Developer 的理想途径。眼下正有很多软件包等 着好的维护者来接手(参看第 2.2 节 “选择你的程序”)。     在这篇文档里，我们的重点在于打包的技术细节，所以请参考以下的文档 来了解 Debian 是如何运转的。 * Debian: 17 years of Free Software, "do-ocracy", and democracy (http://upsilon.cc/~zack/talks/2011/20110321-taipei.pdf) (介 绍性幻灯片) * How can you help Debian? (http://www.debian.org/intro/help) (官方文档) * The Debian GNU/Linux FAQ, Chapter 13 - "Contributing to the     Debian Project" (http://www.debian.org/doc/FAQ/ ch-contributing) (半官方文档) * Debian Wiki, HelpDebian (http://wiki.debian.org/HelpDebian) (补充材料) * Debian New Member site (http://nm.debian.org/) (官方站点) * Debian Mentors FAQ (http://wiki.debian.org/DebianMentorsFaq) (补充文档) 1.2. 开发时需要的软件 在开始之前，你需要确认你是否已经正确安装了开发所需要的附加软件包     。注意这些软件包不包含任何已经被标记为 essential 或 required —— 我们假设你已经安装了它们。 The following packages come with the standard Debian     installation, so you probably have them already (along with any additional packages they depend on). Still, you should check it with aptitude show package or with dpkg -s package. The most important package to install on your development system     is the build-essential package. Once you try to install that, it will pull in other packages required to have a basic build environment. For some types of packages, that is all you will require;     however, there is another set of packages that while not essential for all package builds are useful to have installed or may be required by your package: * autoconf, automake, and autotools-dev - many newer programs use configure scripts and Makefile files preprocessed with the help of programs like these (see info autoconf, info automake). autotools-dev keeps up-to-date versions of certain auto files and has documentation about the best way to use those files. * dh-make 和 debhelper - dh-make 是用于创建我们示例软件包骨架所 必须的，它会使用 debhelper 中的一些工具来创建软件包。他们不是 创建软件包所必须的，但对新维护人员而言，我们强烈推荐使用。它 使得整个过程极为简化，并易于在将来维护。(参看 dh_make(8)、 debhelper(1)、/usr/share/doc/debhelper/README) ^[3] * devscripts - this package contains some useful scripts that can be helpful for maintainers, but they are also not necessary for building packages. Packages recommended and suggested by this package are worth looking into. (See /usr/ share/doc/devscripts/README.gz.) * fakeroot - this utility lets you emulate being root which is necessary for some parts of the build process. (See fakeroot (1).) * file - this handy program can determine what type a file is. (See file(1).) * gfortran - the GNU Fortran 95 compiler, necessary if your program is written in Fortran. (See gfortran(1).) * git - this package provides a popular version control system designed to handle very large projects with speed and efficiency; it is used for many high profile open source projects, most notably the Linux kernel. (See git(1), git Manual (/usr/share/doc/git-doc/index.html).) * gnupg - a tool that enables you to digitally sign packages. This is especially important if you want to distribute it to other people, and you will certainly be doing that when your work gets included in the Debian distribution. (See gpg(1).)     * gpc - the GNU Pascal compiler, necessary if your program is written in Pascal. Worthy of note here is fp-compiler, the Free Pascal Compiler, which is also good at this task. (See gpc(1), ppc386(1).) * lintian - this is the Debian package checker, which can let you know of any common mistakes after you build the package, and explains the errors found. (See lintian(1), Lintian User's Manual (/usr/share/doc/lintian/lintian.html/ index.html) .) * patch - this very useful utility will take a file containing a difference listing (produced by the diff program) and apply it to the original file, producing a patched version. (See patch(1).) * patchutils - 此软件包提供了一些可以帮助处理补丁的工具，如 lsdiff、interdiff 和 filterdiff 命令。 * pbuilder - 这个软件包提供了创建和维护 chroot 环境。在此 chroot 环境中编译 Debian 软件包可以检查编译依赖是否合适并避免 FTBFS (Fails To Build From Source，从源代码编译失败)的 Bug。 (参看 pbuilder(8) 和 pdebuild(1)) * perl - Perl is one of the most used interpreted scripting languages on today's Unix-like systems, often referred to as Unix's Swiss Army Chainsaw. (See perl(1).) * python - Python is another of the most used interpreted scripting languages on the Debian system, combining remarkable power with very clear syntax. (See python(1).) * quilt - this package helps you to manage large numbers of patches by keeping track of the changes each patch makes. Patches can be applied, un-applied, refreshed, and more. (See quilt(1), and /usr/share/doc/quilt/quilt.pdf.gz.) * xutils-dev - some programs, usually those made for X11, also use these programs to generate Makefile files from sets of macro functions. (See imake(1), xmkmf(1).) The short descriptions that are given above only serve to introduce you to what each package does. Before continuing please read the documentation of each relevant program including ones     installed through the package dependency such as make, at least, for the standard usage. It may seem like heavy going now, but later on you'll be very glad you read it. If you have specific questions later, I would suggest re-reading the documents mentioned above. 1.3. Documentation needed for development     以下是非常重要的文档，你应该在读本文档时同时参看它们： * debian-policy - the Debian Policy Manual (http:// www.debian.org/doc/devel-manuals#policy) includes explanations of the structure and contents of the Debian archive, several OS design issues, the Filesystem Hierarchy Standard (http://www.debian.org/doc/packaging-manuals/fhs/ fhs-2.3.html) (FHS, which says where each file and directory should be), etc. For you, the most important thing is that it describes requirements that each package must satisfy to be included in the distribution. (See the local copies of /usr/     share/doc/debian-policy/policy.pdf.gz and /usr/share/doc/ debian-policy/fhs/fhs-2.3.pdf.gz.) * developers-reference - the Debian Developer's Reference (http://www.debian.org/doc/devel-manuals#devref) describes all matters not specifically about the technical details of packaging, like the structure of the archive, how to rename, orphan, or adopt packages, how to do NMUs, how to manage bugs, best packaging practices, when and where to upload etc. (See the local copy of /usr/share/doc/developers-reference/ developers-reference.pdf.)     The following is the important documentation which you should read along with this document: * Autotools Tutorial (http://www.lrde.epita.fr/~adl/ autotools.html) provides a very good tutorial for the GNU Build System known as the GNU Autotools whose most important components are Autoconf, Automake, Libtool, and gettext. * gnu-standards - this package contains two pieces of     documentation from the GNU project: GNU Coding Standards (http://www.gnu.org/prep/standards/html_node/index.html) , and Information for Maintainers of GNU Software (http:// www.gnu.org/prep/maintain/html_node/index.html) . Although Debian does not require these to be followed, these are still helpful as guidelines and common sense. (See the local copies of /usr/share/doc/gnu-standards/standards.pdf.gz and /usr/ share/doc/gnu-standards/maintain.pdf.gz.) If this document contradicts any of the documents mentioned     above, they are correct. Please file a bug report on the maint-guide package using reportbug.     The following is an alternative tutorial documentation which you may read along with this document:     * Debian Packaging Tutorial (http://www.debian.org/doc/ packaging-manuals/packaging-tutorial/packaging-tutorial) 1.4. 到何处寻求帮助     Before you decide to ask your question in some public place, please read the fine documentation. * files in /usr/share/doc/package for all pertinent packages * contents of man command for all pertinent commands * contents of info command for all pertinent commands     * contents of debian-mentors@lists.debian.org mailing list archive (http://lists.debian.org/debian-mentors/) * contents of debian-devel@lists.debian.org mailing list archive (http://lists.debian.org/debian-devel/)     You can use web search engines more effectively by including search strings such as site:lists.debian.org to limit the domain. Making a small test package is a good way to learn details of     packaging. Inspecting existing well maintained packages is the best way to learn how other people make packages. If you still have questions about packaging that you couldn't     find answers to in the available documentation and web resources, you can ask them interactively. * debian-mentors@lists.debian.org mailing list (http:// lists.debian.org/debian-mentors/) . (This mailing list is for the novice.)     * debian-devel@lists.debian.org mailing list (http:// lists.debian.org/debian-devel/) . (This mailing list is for the expert.) * IRC (http://www.debian.org/support#irc) such as # debian-mentors.     The more experienced Debian developers will gladly help you, if you ask properly after making your required efforts. When you receive a bug report (yes, actual bug reports!), you will know that it is time for you to dig into the Debian Bug Tracking System (http://www.debian.org/Bugs/) and read the     documentation there, to be able to deal with the reports efficiently. I highly recommend reading the Debian Developer's Reference, 5.8. "Handling bugs" (http://www.debian.org/doc/ manuals/developers-reference/pkgs.html#bug-handling) . 即使以上的问题都解决了，也不能高兴得太早。为什么？因为几个小时或     几天内就会有人开始使用你的软件包，如果你犯了某些严重的错误，将被 无数生气的 Debian 用户的邮件所轰炸…… 只是开个玩笑。:-) 放松一点并准备好处理 Bug 报告，在你的软件包完全符合 Debian 的各项     规范前还需要付出很多努力，处理 Bug 也是对你很好的锻炼(再一次提醒 ，阅读那些必须的文档来了解详情)。祝你好运！ -------------- ^[1] 在写这份文档时，我们默认你使用 squeeze 操作系统。如果你需要     在 lenny 系统上使用本文所记述的方法，则必须安装 backports 仓库中 的 dpkg 和 debhelper 软件包。 ^[2] 在 Debian Reference (http://www.debian.org/doc/manuals/     debian-reference/) 中，你可以了解到使用 Debian 系统的一些基本信息 和关于 Unix 编程的一些指引。     ^[3] There are also some more specialized but similar packages such as dh-make-perl, dh-make-php, etc. 第 2 章 第一步     Let's start by creating a package of your own (or, even better, adopting an existing one). 2.1. Debian package building workflow If you are making a Debian package with an upstream program, the     typical workflow of Debian package building involves generating several specifically named files for each step as follows. * Get a copy of the upstream software, usually in a compressed tar format. o package-version.tar.gz * Add Debian-specific packaging modifications to the upstream program under the debian directory, and create a non-native source package (that is, the set of input files used for Debian package building) in 3.0 (quilt) format.     o package_version.orig.tar.gz o package_version-revision.debian.tar.gz^[4] o package_version-revision.dsc * Build Debian binary packages, which are ordinary installable package files in .deb format (or .udeb format, used by the Debian Installer) from the Debian source package. o package_version-revision_arch.deb Please note that the character separating package and version was     changed from - (hyphen) in the tarball name to _ (underscore) in the Debian package filenames. In the file names above, replace the package part with the package name, the version part with the upstream version, the     revision part with the Debian revision, and the arch part with the package architecture, as defined in the Debian Policy Manual. ^[5] If instead you are making a Debian-specific package with no     upstream, the typical workflow of Debian package building is simpler. * Create a native Debian source package in the 3.0 (native) format using a single compressed tar file in which all files are included.     o package_version.tar.gz o package_version.dsc * Build Debian binary packages from the native Debian source package. o package_version_arch.deb     Each step of this outline is explained with detailed examples in later sections. 2.2. 选择你的程序 You have probably chosen the package you want to create. The     first thing you need to do is check if the package is in the distribution archive already by using the following. * the aptitude command * the Debian packages (http://www.debian.org/distrib/packages)     web page * the Debian Package Tracking System (http:// packages.qa.debian.org/common/index.html) web page If the package already exists, well, install it! :-) If it happens to be orphaned (that is, if its maintainer is set to     Debian QA Group (http://qa.debian.org/) ), you may be able to pick it up if it's still available. You may also adopt a package whose maintainer has filed a Request for Adoption (RFA).^[6]     There are several package ownership status resources. * Work-Needing and Prospective Packages (http://www.debian.org/ devel/wnpp/) * Debian Bug report logs: Bugs in pseudo-package wnpp in     unstable (http://bugs.debian.org/wnpp) * Debian Packages that Need Lovin' (http://wnpp.debian.net/) * Browse wnpp bugs based on debtags (http://members.hellug.gr/ serzan/wnpp/) As a side note, it's important to point out that Debian already has packages for most kinds of programs, and the number of packages already in the Debian archive is much larger than that     of contributors with upload rights. Thus, contributions to packages already in the archive are far more appreciated (and more likely to receive sponsorship) by other developers ^[7]. You can contribute in various ways. * 接手被抛弃而仍然被很多人使用的软件包。 * 加入打包小组 (http://wiki.debian.org/Teams) 。     * 为某些常用的软件包分类 Bug。 * 在需要时准备 QA 或 NMU 上传 (http://www.debian.org/doc/ developers-reference/pkgs.html#nmu-qa-upload) 。 If you are able to adopt the package, get the sources (with something like apt-get source packagename) and examine them. This document unfortunately doesn't include comprehensive information     about adopting packages. Thankfully you shouldn't have a hard time figuring out how the package works since someone has already done the initial setup for you. Keep reading, though; a lot of the advice below will still be applicable for your case.     如果你要制作的软件包是全新的，并且希望它出现在 Debian 中，请按照 以下的步骤进行： * First, you must know that the program works, and have tried it for some time to confirm its usefulness. * You must check that no one else is already working on the package on the Work-Needing and Prospective Packages (http:// www.debian.org/devel/wnpp/) site. If no one else is working on it, file an ITP (Intent To Package) bug report to the wnpp pseudo-package using reportbug. If someone's already on it, contact them if you feel you need to. If not - find another interesting program that nobody is maintaining. * The software must have a license. o For the main section, Debian Policy requires it to be fully compliant with the Debian Free Software Guidelines (DFSG (http://www.debian.org/social_contract#guidelines) ) and not to require a package outside of main for compilation or execution. This is the desired case. o For the contrib section, it must comply with the DFSG but it may require a package outside of main for compilation or execution.     o For the non-free section, it may be non-compliant with the DFSG but it must be distributable. o 如果你不清楚你的软件应该分入哪一类，则把许可证文本发送到 debian-legal@lists.debian.org (http://lists.debian.org/ debian-legal/) 请他人提出意见。 * The program should not introduce security and maintenance concerns to the Debian system. o The program should be well documented and its code needs to be understandable (i.e. not obfuscated). o You should contact the program's author(s) to check if they agree with packaging it and are amicable to Debian. It is important to be able to consult with the author(s) in case of any problems with the program, so don't try to package unmaintained software. o The program certainly should not run setuid root, or even better, it shouldn't need to be setuid or setgid to anything. o The program should not be a daemon, or go in an */sbin directory, or open a port as root. Of course, the last one is just a safety measures, and intended     to save you from enraging users if you do something wrong in some setuid daemon... When you gain more experience in packaging, you'll be able to package such software. As a new maintainer, you are encouraged to get some experience in     packaging with easier packages and discouraged from creating complicated packages. * Simple packages o single binary package, arch = all (collection of data such as wallpaper graphics) o single binary package, arch = all (executables written in an interpreted language such as POSIX shell) * Intermediate complexity packages o single binary package, arch = any (ELF binary executables compiled from languages such as C and C++) o multiple binary packages, arch = any + all (packages for ELF binary executables + documentation) o upstream source in a format other than tar.gz or tar.bz2     o upstream source containing undistributable contents * High complexity packages o interpreter module package used by other packages o generic ELF library package used by other packages o multiple binary packages including an ELF library package o source package with multiple upstream sources o kernel module packages o kernel patch packages o any package with non-trivial maintainer scripts Packaging high complexity packages is not too hard, but it     requires a bit more knowledge. You should seek specific guidance for every complex feature. For example, some languages have their own sub-policy documents: * Perl policy (http://www.debian.org/doc/packaging-manuals/ perl-policy/)     * Python policy (http://www.debian.org/doc/packaging-manuals/ python-policy/) * Java policy (http://www.debian.org/doc/packaging-manuals/ java-policy/) There is another old Latin saying: fabricando fit faber (practice makes perfect). It is highly recommended to practice and     experiment with all the steps of Debian packaging with simple packages while reading this tutorial. A trivial upstream tarball hello-sh-1.0.tar.gz created as followings may offer a good starting point.^[8] $ mkdir -p hello-sh/hello-sh-1.0; cd hello-sh/hello-sh-1.0 $ cat > hello < autoreconf -+-> configure Makefile.am -----+ | +-> Makefile.in src/Makefile.am -+ | +-> src/Makefile.in     | +-> config.h.in automake aclocal aclocal.m4 autoheader     编辑 configure.ac 和 Makefile.am 等文件需要一些关于 autoconf 和 automake 的知识。参看 info autoconf 和 info automake。 The second step of the Autotools workflow is usually that the     user obtains this distributed source and runs ./configure && make in the source directory to compile the program into an executable command binary. Makefile.in -----+ +-> Makefile -----+-> make -> binary src/Makefile.in -+-> ./configure -+-> src/Makefile -+     config.h.in -----+ +-> config.h -----+ | config.status -+ config.guess --+ You can change many things in the Makefile; for instance you can     change the default location for file installation using the option ./configure --prefix=/usr. Although it is not required, updating the configure and other     files with autoreconf -i -f may improve the compatibility of the source. ^[13]     CMake is an alternative build system. You can recognize such sources by the CMakeLists.txt file. 2.6. 软件包名称和版本 If the upstream source comes as gentoo-0.9.12.tar.gz, you can     take gentoo as the (source) package name and 0.9.12 as the upstream version. These are used in the debian/changelog file described later in 第 4.3 节 “changelog”, too. Although this simple approach works most of the times, you may     need to adjust package name and upstream version by renaming the upstream source to follow Debian Policy and existing convention. You must choose the package name to consist only of lower case letters (a-z), digits (0-9), plus (+) and minus (-) signs, and     periods (.). It must be at least two characters long, must start with an alphanumeric character, and must not be the same as existing ones. It is a good idea to keep its length within 30 characters. ^[14] If upstream uses some generic term such as test-suite for its     name, it is a good idea to rename it to identify its contents explicitly and avoid namespace pollution. ^[15] You should choose the upstream version to consist only of     alphanumerics (0-9A-Za-z), plus (+), tildes (~), and periods (.). It must start with a digit (0-9). ^[16] It is good idea to keep its length within 8 characters if possible. ^[17] If upstream does not use a normal versioning scheme such as 2.30.32 but uses some kind of date such as 11Apr29, a random codename string, or a VCS hash value as part of the version, make sure to remove them from the upstream version. Such information can be recorded in the debian/changelog file. If you need to     invent a version string, use the YYYYMMDD format such as 20110429 as upstream version. This ensures that dpkg interprets later versions correctly as upgrades. If you need to ensure smooth transition to the normal version scheme such as 0.1 in future, use the 0~YYMMDD format such as 0~110429 as upstream version, instead.     Version strings ^[18] can be compared using dpkg(1) as follows.     $ dpkg --compare-versions ver1 op ver2     The version comparison rule can be summarized as: * Strings are compared from the head to the tail. * Letters are larger than digits. * Numbers are compared as integers.     * Letters are compared in ASCII code order. * There are special rules for period (.), plus (+), and tilde (~) characters, as follows. 0.0 < 0.5 < 0.10 < 0.99 < 1 < 1.0~rc1 < 1.0 < 1.0+b1 < 1.0+nmu1 < 1.1 < 2.0 One tricky case occurs when upstream releases gentoo-0.9.12-ReleaseCandidate-99.tar.gz as the pre-release of     gentoo-0.9.12.tar.gz. You need to make sure that the upgrade works properly by renaming the upstream source to gentoo-0.9.12~rc99.tar.gz. 2.7. Setting up dh_make Set up the shell environment variables $DEBEMAIL and $DEBFULLNAME     so that various Debian maintenance tools recognize your email address and name to use for packages. ^[19] $ cat >>~/.bashrc < 5 Build-Depends: debhelper (>=9) 6 Standards-Version: 3.9.4     7 Homepage: 8 9 Package: gentoo 10 Architecture: any 11 Depends: ${shlibs:Depends}, ${misc:Depends} 12 Description: 13     (注：我为它添加了行号。)     Lines 1-7 are the control information for the source package. Lines 9-13 are the control information for the binary package.     第 1 行是源代码包的名称。     第 2 行是该源码包要进入发行版中的分类。 As you may have noticed, the Debian archive is divided into multiple areas: main (the free software), non-free (the not really free software) and contrib (free software that depends on non-free software). Each of these is divided into sections that     classify packages into rough categories. So we have admin for administrator-only programs, devel for programmer tools, doc for documentation, libs for libraries, mail for email readers and daemons, net for network apps and daemons, x11 for X11 programs that don't fit anywhere else, and many more. ^[28]     我们将本例设置为 x11。( main/ 前缀是默认值，可以省略。)     Line 3 describes how important it is that the user installs this package. ^[29] * The optional priority will usually work for new packages that do not conflict with others claiming required, important, or     standard priority. * extra 优先级适用于与其他非 extra 优先级软件包冲突的新软件包。 Section and priority are used by front-ends like aptitude when they sort packages and select defaults. Once you upload the     package to Debian, the value of these two fields can be overridden by the archive maintainers, in which case you will be notified by email.     由于这是一个常规优先级的软件，并不与其他软件包冲突，我们将优先级 改为 optional。 Line 4 is the name and email address of the maintainer. Make sure that this field includes a valid To header for email, because     after you upload it, the bug tracking system will use it to deliver bug emails to you. Avoid using commas, ampersands, or parentheses. Line 5 includes the list of packages required to build your package as the Build-Depends field. You can also have the Build-Depends-Indep field as an additional line, here. ^[30] Some packages like gcc and make which are required by the     build-essential package are implied. If you need to have other tools to build your package, you should add them to these fields. Multiple entries are separated with commas; read on for the explanation of binary package dependencies to find out more about the syntax of these lines. * For all packages packaged with the dh command in the debian/ rules file, you must have debhelper (>=9) in the Build-Depends field to satisfy the Debian Policy requirement for the clean target. * Source packages which have binary packages with Architecture: any are rebuilt by the autobuilder. Since this autobuilder procedure installs only the packages listed in the     Build-Depends field before running debian/rules build (see 第  6.2 节 “自动编译系统”), the Build-Depends field needs to list practically all the required packages and Build-Depends-Indep is rarely used. * For source packages with binary packages all of which are Architecture: all, the Build-Depends-Indep field may list all the required packages unless they are already listed in the Build-Depends field to satisfy the Debian Policy requirement for the clean target.     如果你不知道应该使用哪一个，则使用 Build-Depends 以保证安全。^[31 ]     要找出编译你的软件所需的软件包可以使用这个命令：     $ dpkg-depcheck -d ./configure     To manually find exact build dependencies for /usr/bin/foo, execute     $ objdump -p /usr/bin/foo | grep NEEDED     对于列出的每个库，例如 libfoo.so.6，运行：     $ dpkg -S libfoo.so.6 Then just take the -dev version of every package as a     Build-Depends entry. If you use ldd for this purpose, it will report indirect lib dependencies as well, resulting in the problem of excessive build dependencies.     gentoo 需要 xlibs-dev、libgtk1.2-dev 和 libglib1.2-dev 才能编译， 所以我们将这些软件包加在 debhelper 之后。     第 6 行是此软件包所依据的 Debian Policy Manual (http:// www.debian.org/doc/devel-manuals#policy) 标准版本号。     On line 7 you can put the URL of the software's upstream homepage.     第 9 行是二进制软件包的名称。通常情况下与源代码包相同，但不是必须 的。 Line 10 describes the architectures the binary package can be     compiled for. This value is usually one of the following depending on the type of the binary package. ^[32] * Architecture: any o The generated binary package is an architecture dependent one usually in a compiled language.     * Architecture: all o The generated binary package is an architecture independent one usually consisting of text, images, or scripts in an interpreted language. We leave line 10 as is since this is written in C.     dpkg-gencontrol(1) will fill in the appropriate architecture value for any machine this source package gets compiled on. 如果你的软件包是平台独立的(例如一个 shell 或 Perl 脚本，或一些文     档)，将这项改变为 all，然后继续阅读第 4.4 节 “rules” 中关于使用 binary-indep 指令替代 binary-arch 来编译软件包的内容。 第 11 行显示了 Debian 软件包系统中最强大的特性之一。每个软件包都     可以和其他软件包有各种不同的关系。除 Depends 外，还有 Recommends 、Suggests、Pre-Depends、Breaks、Conflicts、Provides 和 Replaces 。 The package management tools usually behave the same way when     dealing with these relations; if not, it will be explained. (See dpkg(8), dselect(8), apt(8), aptitude(1), etc.)     Here is a simplified description of package relationships. ^[33] * Depends 此软件包仅当它依赖的软件包均已安装后才可以安装。此处写明你的 程序所必须的软件包。 * Recommends Use this for packages that are not strictly necessary but are typically used with your program. When a user installs your program, all front-ends will probably prompt them to install the recommended packages. aptitude and apt-get install recommended packages along with your package by default (but the user can disable this behavior). dpkg will ignore this field. * Suggests Use this for packages which will work nicely with your program but are not at all necessary. When a user installs your program, they will probably not be prompted to install suggested packages. aptitude can be configured to install suggested packages along with your package but this is not its default. dpkg and apt-get will ignore this field. * Pre-Depends 此项中的依赖强于 Depends 项。软件包仅在预依赖的软件包已经安装 后才可以正常安装并且正确配置后才可以正常安装。在使用此项时应 非常慎重，仅当在 debian-devel@lists.debian.org (http://     lists.debian.org/debian-devel/) 邮件列表讨论后才能使用。记住 ：根本就不要用这项。 :-) * Conflicts 仅当所有冲突的软件包都已经删除后此软件包才可以安装。当程序在 某些特定软件包存在时根本无法运行或存在严重问题时使用此项。 * Breaks When installed the package will break all the listed packages. Normally a Breaks entry specifies that it applies to versions earlier than a certain value. The resolution is generally to use higher-level package management tools to upgrade the listed packages. * Provides For some types of packages where there are multiple alternatives virtual names have been defined. You can get the full list in the virtual-package-names-list.txt.gz (http:// www.debian.org/doc/packaging-manuals/ virtual-package-names-list.txt) file. Use this if your program provides a function of an existing virtual package. * Replaces 当你的程序要替换其他软件包的某些文件，或是完整地替换另一个软 件包(与 Conflicts 一起使用)。列出的软件包中的某些文件会被你的 软件包所覆盖。 所有的这些项都使用相同的语法。它们是一个软件包列表，软件包名称间     使用半角逗号分隔。也可以写出有多个可选的软件包名称，这些软件包使 用 | 符号分隔。 The fields may restrict their applicability to particular versions of each named package. The restriction of each individual package is listed in parentheses after its name, and     should contain a relation from the list below followed by a version number value. The relations allowed are: <<, <=, =, >=, and >> for strictly lower, lower or equal, exactly equal, greater or equal, and strictly greater, respectively. For 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)     The last feature you need to know about is ${shlibs:Depends}, $ {perl:Depends}, ${misc:Depends}, etc. dh_shlibdeps(1) calculates shared library dependencies for binary     packages. It generates a list of ELF executables and shared libraries it has found for each binary package. This list is used for substituting ${shlibs:Depends}. dh_perl(1) calculates Perl dependencies. It generates a list of a     dependencies on perl or perlapi for each binary package. This list is used for substituting ${perl:Depends}. Some debhelper commands may cause the generated package to depend     on some additional packages. All such commands generate a list of required packages for each binary package. This list is used for substituting ${misc:Depends}. dh_gencontrol(1) generates DEBIAN/control for each binary package     while substituting ${shlibs:Depends}, ${perl:Depends}, $ {misc:Depends}, etc. Having said all that, we can leave the Depends field exactly as     it is now, and insert another line after it saying Suggests: file, because gentoo can use some features provided by the file package.     Line 9 is the Homepage URL. Let's assume this to be at http:// www.obsession.se/gentoo/ (http://www.obsession.se/gentoo/) . Line 12 is the short description. Terminals are conventionally 80     columns wide so this shouldn't be longer than about 60 characters. I'll change it to fully GUI-configurable, two-pane X file manager. Line 13 is where the long description goes. This should be a paragraph which gives more details about the package. Column 1 of     each line should be empty. There must be no blank lines, but you can put a single . (dot) in a column to simulate that. Also, there must be no more than one blank line after the long description. ^[34] We can insert Vcs-* fields to document the Version Control System     (VCS) location between lines 6 and 7. ^[35] Let's assume that the gentoo package has its VCS located in the Debian Alioth Git Service at git://git.debian.org/git/collab-maint/gentoo.git.     到此为止，我们做好了 control 文件： 1 Source: gentoo 2 Section: x11 3 Priority: optional 4 Maintainer: Josip Rodin 5 Build-Depends: debhelper (>=9), xlibs-dev, libgtk1.2-dev, libglib1.2-dev 6 Standards-Version: 3.9.4 7 Vcs-Git: git://git.debian.org/git/collab-maint/gentoo.git 8 Vcs-browser: http://git.debian.org/?p=collab-maint/gentoo.git 9 Homepage: http://www.obsession.se/gentoo/ 10 11 Package: gentoo 12 Architecture: any 13 Depends: ${shlibs:Depends}, ${misc:Depends}     14 Suggests: file 15 Description: fully GUI-configurable, two-pane X file manager 16 gentoo is a two-pane file manager for the X Window System. gentoo lets the 17 user do (almost) all of the configuration and customizing from within the 18 program itself. If you still prefer to hand-edit configuration files, 19 they're fairly easy to work with since they are written in an XML format. 20 . 21 gentoo features a fairly complex and powerful file identification system, 22 coupled to an object-oriented style system, which together give you a lot 23 of control over how files of different types are displayed and acted upon. 24 Additionally, over a hundred pixmap images are available for use in file 25 type descriptions. 26 . 29 gentoo was written from scratch in ANSI C, and it utilizes the GTK+ toolkit 30 for its interface.     (注：我为它添加了行号。) 4.2. copyright This file contains information about the copyright and license of the upstream sources. Debian Policy Manual, 12.5 "Copyright     information" (http://www.debian.org/doc/debian-policy/ ch-docs.html#s-copyrightfile) dictates its content and DEP-5: Machine-parseable debian/copyright (http://dep.debian.net/deps/ dep5/) provides guidelines for its format. dh_make 可以给出一个 copyright 文件的模板。在这里我们使用     --copyright gpl2 参数来获得一个模板写明 gentoo 软件包是发布于 GPL-2 许可证下。 You must fill in missing information to complete this file, such as the place you got the package from, the actual copyright notice, and the license. For certain common free software     licenses (GNU GPL-1, GNU GPL-2, GNU GPL-3, LGPL-2, LGPL-2.1, LGPL-3, GNU FDL-1.2, GNU FDL-1.3, Apache-2.0, or the Artistic license), you can just refer to the appropriate file in the /usr/ share/common-licenses/ directory that exists on every Debian system. Otherwise, you must include the complete license.     In short, here's what gentoo's copyright file should look like: 1 Format-Specification: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135 2 Name: gentoo 3 Maintainer: Josip Rodin 4 Source: http://sourceforge.net/projects/gentoo/files/ 5 6 Copyright: 1998-2010 Emil Brink 7 License: GPL-2+ 8 9 Files: icons/* 10 Copyright: 1998 Johan Hanson 11 License: GPL-2+ 12 13 Files: debian/* 14 Copyright: 1998-2010 Josip Rodin 15 License: GPL-2+ 16     17 License: GPL-2+ 18 This program is free software; you can redistribute it and/or modify 19 it under the terms of the GNU General Public License as published by 20 the Free Software Foundation; either version 2 of the License, or 21 (at your option) any later version. 22 . 23 This program is distributed in the hope that it will be useful, 24 but WITHOUT ANY WARRANTY; without even the implied warranty of 25 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 26 GNU General Public License for more details. 27 . 28 You should have received a copy of the GNU General Public License along 29 with this program; if not, write to the Free Software Foundation, Inc., 30 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. 31 . 32 On Debian systems, the full text of the GNU General Public 33 License version 2 can be found in the file 34 `/usr/share/common-licenses/GPL-2'.     (注：我为它添加了行号。) Please follow the HOWTO provided by the ftpmasters and sent to     debian-devel-announce: http://lists.debian.org/ debian-devel-announce/2006/03/msg00023.html (http:// lists.debian.org/debian-devel-announce/2006/03/msg00023.html) . 4.3. changelog This is a required file, which has a special format described in Debian Policy Manual, 4.4 "debian/changelog" (http://     www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog) . This format is used by dpkg and other programs to obtain the version number, revision, distribution, and urgency of your package. 对于你而言，详细描述你所做出的更改也是很好且很重要的。它将帮助下     载你的软件包的人了解这个软件包中是否有他们需要知道的事情。它会被 作为 /usr/share/doc/gentoo/changelog.Debian.gz 保存在二进制包中。     dh_make created a default one, and this is what it looks like: 1 gentoo (0.9.12-1) unstable; urgency=low 2     3 * Initial release (Closes: #nnnn) 4 5 -- Josip Rodin Mon, 22 Mar 2010 00:37:31 +0100 6     (注：我为它添加了行号。) Line 1 is the package name, version, distribution, and urgency.     The name must match the source package name; distribution should be unstable, and urgency shouldn't be changed to anything higher than low. :-) Lines 3-5 are a log entry, where you document changes made in this package revision (not the upstream changes - there is a special file for that purpose, created by the upstream authors,     which you will later install as /usr/share/doc/gentoo/ changelog.gz). Let's assume your ITP (Intent To Package) bug report number was 12345. New lines must be inserted just below the uppermost line that begins with * (asterisk). You can do it with dch(1), or manually with a text editor. In order to prevent a package being accidentally uploaded before     completing the package, it is good idea to change the distribution value to an invalid distribution value UNRELEASED.     最后它会成为以下的样子： 1 gentoo (0.9.12-1) UNRELEASED; urgency=low 2 3 * Initial Release. Closes: #12345     4 * This is my first Debian package. 5 * Adjusted the Makefile to fix $(DESTDIR) problems. 6 7 -- Josip Rodin Mon, 22 Mar 2010 00:37:31 +0100 8     (注：我为它添加了行号。) Once you are satisfied with all the changes and documented them     in changelog, you should change the distribution value from UNRELEASED to the target distribution value unstable (or even experimental). ^[36]     你可以在关于更新的第 9 章更新软件包中了解更多关于 changelog 的内 容。 4.4. rules Now we need to take a look at the exact rules which dpkg-buildpackage(1) will use to actually create the package.     This file is in fact another Makefile, but different from the one (s) in the upstream source. Unlike other files in debian, this one is marked as executable. 4.4.1. Targets of the rules file Every rules file, like any other Makefile, consists of several rules, each of which defines a target and how it is carried out. ^[37] A new rule begins with its target declaration in the first     column. The following lines beginning with the TAB code (ASCII 9) specify the recipe for carrying out that target. Empty lines and lines beginning with # (hash) are treated as comments and ignored. ^[38] A rule that you want to execute is invoked by its target name as     a command line argument. For example, debian/rules build and fakeroot make -f debian/rules binary execute rules for build and binary targets respectively.     Here is a simplified explanation of the targets: * clean target: to clean all compiled, generated, and useless files in the build-tree. (Required) * build target: to build the source into compiled programs and formatted documents in the build-tree. (Required) * build-arch target: to build the source into arch-dependent compiled programs in the build-tree. (Required) * build-indep target: to build the source into arch-independent formatted documents in the build-tree. (Required) * install target: to install files into a file tree for each binary package under the debian directory. If defined,     binary* targets effectively depend on this target. (Optional) * binary target: to create all binary packages (effectively a combination of binary-arch and binary-indep targets). (Required)^[39] * binary-arch target: to create arch-dependent (Architecture: any) binary packages in the parent directory. (Required)^[40] * binary-indep target: to create arch-independent (Architecture: all) binary packages in the parent directory. (Required)^[41] * get-orig-source target: to obtain the most recent version of the original source package from an upstream archive. (Optional) You are probably overwhelmed by now, but things are much simpler     upon examination of the rules file that dh_make gives us as a default. 4.4.2. 默认的 rules 文件     新版本的 dh_make 会生成一个使用 dh 命令的非常简单但非常强大的默认 的 rules 文件： 1 #!/usr/bin/make -f 2 # -*- makefile -*- 3 # Sample debian/rules that uses debhelper. 4 # This file was originally written by Joey Hess and Craig Small. 5 # As a special exception, when this file is copied by dh-make into a 6 # dh-make output file, you may use that output file without restriction.     7 # This special exception was added by Craig Small in version 0.37 of dh-make. 8 9 # Uncomment this to turn on verbose mode. 10 #export DH_VERBOSE=1 11 12 %: 13 dh $@     (I've added the line numbers. In the actual rules file, the leading spaces are a TAB code.)     可能在 shell 或 Perl 脚本中你已经对第一行的形式很熟悉了，它告诉操 作系统这个文件应使用 /usr/bin/make 处理。 Line 10 can be uncommented to set the DH_VERBOSE variable to 1, so that the dh command outputs which dh_* commands it is executing. You can also add a line export DH_OPTIONS=-v here, so     that each dh_* command outputs which commands it is executing. This helps you to understand exactly what is going on behind this simple rules file and to debug its problems. This new dh is designed to form a core part of the debhelper tools, and not to hide anything from you. Lines 12 and 13 are where all the work is done with an implicit rule using the pattern rule. The percent sign means "any     targets", which then call a single program, dh, with the target name. ^[42] The dh command is a wrapper script which runs appropriate sequences of dh_* programs depending on its argument. ^[43] * debian/rules clean runs dh clean, which in turn runs the following: 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; 实际 执行的命令为^[44]： 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 dh binary 一样的命令， 但 dh_strip、dh_makeshlibs 和 dh_shlibdeps 除外，其他命令则均 附加-i 选项。 The functions of dh_* commands are largely self-evident from     their names. ^[45] There are a few notable ones that are worth giving (over)simplified explanations here assuming a typical build environment based on a Makefile. ^[46] * dh_auto_clean usually executes the following if a Makefile exists with the distclean target. ^[47] make distclean * dh_auto_configure 在 ./configure 存在时通常执行以下命令(省略了部 分参数以方便此处阅读)。 ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var ... * dh_auto_build 通常使用以下命令执行 Makefile 中的第一个 target。     make * dh_auto_test usually executes the following if a Makefile exists with the test target. ^[48] make test * dh_auto_install usually executes the following if a Makefile exists with the install target (line folded for readability). make install \ DESTDIR=/path/to/package_version-revision/debian/package All targets which require the fakeroot command will contain     dh_testroot, which exits with an error if you are not using this command to pretend to be root. The important part to know about the rules file created by     dh_make is that it is just a suggestion. It will work for most packages but for more complicated ones, don't be afraid to customize it to fit your needs. Although install is not a required target, it is supported.     fakeroot dh install behaves like fakeroot dh binary but stops after dh_fixperms. 4.4.3. 定制 rules 文件     有很多方法来定制使用新的 dh 命令创建的 rules 文件。     dh $@ 命令可以按以下方式定制。^[49] * Add support for the dh_python2 command. (The best choice for Python.) ^[50] o Include the python package in Build-Depends. o Use dh $@ --with python2. o This handles Python modules using the python framework. * Add support for the dh_pysupport command. (deprecated) o Include the python-support package in Build-Depends. o Use dh $@ --with pysupport. o 这会使用 python-support 框架处理 Python 模块。 * Add support for the dh_pycentral command. (deprecated) o Include the python-central package in Build-Depends. o Use dh $@ --with python-central instead. o 这样会同时停用 dh_pysupport 命令。 o 这会使用 python-central 框架处理 Python 模块。 * Add support for the dh_installtex command. o Include the tex-common package in Build-Depends. o Use dh $@ --with tex instead. o This registers Type 1 fonts, hyphenation patterns, and formats with TeX. * Add support for the dh_quilt_patch and dh_quilt_unpatch commands. o Include the quilt package in Build-Depends. o Use dh $@ --with quilt instead. o This applies and un-applies patches to the upstream source from files in the debian/patches directory for a source package in the 1.0 format. o This is not needed if you use the new 3.0 (quilt) source     package format. * Add support for the dh_dkms command. o Include the dkms package in Build-Depends. o Use dh $@ --with dkms instead. o This correctly handles DKMS usage by kernel module packages. * Add support for the dh_autotools-dev_updateconfig and dh_autotools-dev_restoreconfig commands. o Include the autotools-dev package in Build-Depends. o Use dh $@ --with autotools-dev instead. o 这会自动更新或还原 config.sub 和 config.guess 文件。 * Add support for the dh_autoreconf and dh_autoreconf_clean commands. o Include the dh-autoreconf package in Build-Depends. o Use dh $@ --with autoreconf instead. o 这样会在编译时更新 GNU 编译系统文件并在编译后对其进行恢复 。 * Add support for the dh_girepository command. o Includes the gobject-introspection package in Build-Depends. o Use dh $@ --with gir instead. o This computes dependencies for packages shipping GObject introspection data and generates the ${gir:Depends} substitution variable for the package dependency. * Add support for the bash completion feature. o Includes the bash-completion package in Build-Depends. o Use dh $@ --with bash-completion instead. o This installs bash completions using a configuration file at debian/package.bash-completion. 很多由新的 dh 命令触发的 dh_* 都可以通过修改 debian 目录中的配置     文件来对其行为进行定制。参看第 5 章 debian 目录下的其他文件和每个 命令的 man 手册页。 You may need to run dh_* commands invoked via the new dh with added arguments, or to run additional commands with them, or to     skip them. For such cases, you create an override_dh_foo target with its rule in the rules file defining an override_dh_foo target for the dh_foo command you want to change. It basically says run me instead. ^[51] Please note that the dh_auto_* commands tend to do more than what has been discussed in this (over)simplified explanation to take     care of all the corner cases. It is a bad idea to use override_dh_* targets to substitute simplified equivalent commands (except for the override_dh_auto_clean target) since it may bypass such smart debhelper features. So, for instance, if you want to store system configuration data in the /etc/gentoo directory instead of the usual /etc directory     for the recent gentoo package using Autotools, you can override the default --sysconfig=/etc argument given by the dh_auto_configure command to the ./configure command by the following.     override_dh_auto_configure: dh_auto_configure -- --sysconfig=/etc/gentoo The arguments given after -- are appended to the default arguments of the auto-executed program to override them. Using     the dh_auto_configure command is better than directly invoking the ./configure command here since it will only override the --sysconfig argument and retains any other, benign arguments to the ./configure command. If the Makefile in the source for gentoo requires you to specify     build as its target to build it ^[52], you create an override_dh_auto_build target to enable this.     override_dh_auto_build: dh_auto_build -- build     This ensures $(MAKE) is run with all the default arguments given by the dh_auto_build command plus the build argument. If the Makefile in the source for gentoo requires you to specify     the packageclean target to clean it for the Debian package instead of using distclean or clean targets, you can create an override_dh_auto_clean target to enable thit.     override_dh_auto_clean: $(MAKE) packageclean If the Makefile in the source for gentoo contains a test target     which you do not want to run for the Debian package building process, you can use an empty override_dh_auto_test target to skip it.     override_dh_auto_test: 如果 gentoo 有某个不常见的上游 changelog 文件名为 FIXES，默认情况     下 dh_installchangelogs 不会安装它。dh_installchangelogs 命令需要 将 FIXES 作为它的参数来安装它。^[53]     override_dh_installchangelogs: dh_installchangelogs FIXES When you use the new dh command, use of explicit targets such as the ones listed in 第 4.4.1 节 “Targets of the rules file”, other     than the get-orig-source target, may make it difficult to understand their exact effects. Please limit explicit targets to override_dh_* targets and completely independent ones, if possible. -------------- ^[27] In this chapter, files in the debian directory are referred     to without the leading debian/ for simplicity whenever the meaning is obvious. ^[28] See Debian Policy Manual, 2.4 "Sections" (http://     www.debian.org/doc/debian-policy/ch-archive.html#s-subsections) and List of sections in sid (http://packages.debian.org/unstable /) .     ^[29] See Debian Policy Manual, 2.5 "Priorities" (http:// www.debian.org/doc/debian-policy/ch-archive.html#s-priorities) . ^[30] See Debian Policy Manual, 7.7 "Relationships between source     and binary packages - Build-Depends, Build-Depends-Indep, Build-Conflicts, Build-Conflicts-Indep" (http://www.debian.org/ doc/debian-policy/ch-relationships.html#s-sourcebinarydeps) . ^[31] This somewhat strange situation is a feature well documented in the Debian Policy Manual, Footnotes 55 (http:// www.debian.org/doc/debian-policy/footnotes.html#f55) . This is     not due to the use of the dh command in the debian/rules file but due to how the dpkg-buildpackage works. The same situation applies to the auto build system for Ubuntu (https:// bugs.launchpad.net/launchpad-buildd/+bug/238141) . ^[32] See Debian Policy Manual, 5.6.8 "Architecture" (http://     www.debian.org/doc/debian-policy/ch-controlfields.html# s-f-Architecture) for exact details. ^[33] See Debian Policy Manual, 7 "Declaring relationships     between packages" (http://www.debian.org/doc/debian-policy/ ch-relationships.html) . ^[34] These descriptions are in English. Translations of these     descriptions are provided by The Debian Description Translation Project - DDTP (http://www.debian.org/intl/l10n/ddtp) . ^[35] See Debian Developer's Reference, 6.2.5. "Version Control     System location" (http://www.debian.org/doc/manuals/ developers-reference/best-pkging-practices.html#bpp-vcs) . ^[36] If you use the dch -r command to make this last change,     please make sure to save the changelog file explicitly by the editor. ^[37] You can start learning how to write Makefile from Debian Reference, 12.2. "Make" (http://www.debian.org/doc/manuals/ debian-reference/ch12#_make) . The full documentation is     available as http://www.gnu.org/software/make/manual/html_node/ index.html (http://www.gnu.org/software/make/manual/html_node/ index.html) or as the make-doc package in the non-free archive area. ^[38] Debian Policy Manual, 4.9 "Main building script: debian/     rules" (http://www.debian.org/doc/debian-policy/ch-source.html# s-debianrules) explains the details.     ^[39] 此 target 被 dpkg-buildpackage 用于第 6.1 节 “完整的(重)构 建” 描述的过程中。     ^[40] 此 target 被 dpkg-buildpackage -B 用于第 6.2 节 “自动编译系 统” 描述的过程中。     ^[41] 此 target 被 dpkg-buildpackage -A 使用。 ^[42] This uses the new debhelper v7+ features. Its design concepts are explained in Not Your Grandpa's Debhelper (http:// joey.kitenet.net/talks/debhelper/debhelper-slides.pdf) presented at DebConf9 by the debhelper upstream. Under lenny, dh_make created a much more complicated rules file with explicit rules     and many dh_* scripts listed for each one, most of which are now unnecessary (and show the package's age). The new dh command is simpler and frees us from doing the routine work "manually". You still have full power to customize the process with override_dh_* targets. See 第 4.4.3 节 “定制 rules 文件”. It is based only on the debhelper package and does not obfuscate the package building process as the cdbs package tends to. ^[43] You can verify the actual sequences of dh_* programs     invoked for a given target without really running them by invoking dh --no-act target or debian/rules -- '--no-act target'. ^[44] The following example assumes your debian/compat has a     value equal or more than 9 to avoid invoking any python support commands automatically. ^[45] For complete information on what all these dh_* scripts do     exactly, and what their other options are, please read their respective manual pages and the debhelper documentation. ^[46] These commands support other build environments such as     setup.py which can be listed by executing dh_auto_build --list in a package source directory. ^[47] It actually looks for the first available target in the     Makefile out of distclean, realclean, or clean, and executes that.     ^[48] It actually looks for the first available target in the Makefile out of test or check, and executes that. ^[49] If a package installs the /usr/share/perl5/Debian/Debhelper     /Sequence/custom_name.pm file, you should activate its customization function by dh $@ --with custom-name. ^[50] Use of the dh_python2 command is preferred over use of     dh_pysupport or dh_pycentral commands. Do not use the dh_python command.     ^[51] 在 lenny 下，如果你希望更改某个 dh_* 脚本的行为，你需要在 rules 中找到相应的行然后进行调整。     ^[52] dh_auto_build without any arguments will execute the first target in the Makefile. ^[53] The debian/changelog and debian/NEWS files are always     automatically installed. The upstream changelog is found by converting filenames to lower case and matching them against changelog, changes, changelog.txt, and changes.txt. 第 5 章 debian 目录下的其他文件 To control most of what debhelper does while building the package, you put optional configuration files under the debian directory. This chapter will provide an overview of what each of     these does and its format. Please read the Debian Policy Manual (http://www.debian.org/doc/devel-manuals#policy) and Debian Developer's Reference (http://www.debian.org/doc/devel-manuals# devref) for guidelines for packaging. The dh_make command will create some template configuration files under the debian directory. Most of them come with filenames     suffixed by .ex. Some of them come with filenames prefixed by the binary package name such as package. Take a look at all of them. ^[54] Some template configuration files for debhelper may not be     created by the dh_make command. In such cases, you need to create them with an editor.     If you wish or need to activate any of these, please do the following: * rename template files by removing the .ex or .EX suffix if they have one; * rename the configuration files to use the actual binary package name in place of package;     * modify template file contents to suit your needs; * remove template files which you do not need; * modify the control file (see 第 4.1 节 “control”), if necessary; * 如果需要，修改 rules 文件(参看第 4.4 节 “rules”)。 Any debhelper configuration files without a package prefix, such as install, apply to the first binary package. When there are     many binary packages, their configurations can be specified by prefixing their name to their configuration filenames such as package-1.install, package-2.install, etc. 5.1. README.Debian     所有关于你的 Debian 版本与原始版本间的额外信息或差别都应在这里记 录。     dh_make created a default one; this is what it looks like: gentoo for Debian     ----------------- -- Josip Rodin , Wed, 11 Nov 1998 21:02:14 +0100     如果你没有需要写在这里的东西，则删除这个文件。参看 dh_installdocs (1) 5.2. compat     The compat file defines the debhelper compatibility level. Currently, you should set it to the debhelper v9 as follows:     $ echo 9 > debian/compat 5.3. conffiles One of the most annoying things about software is when you spend a great deal of time and effort customizing a program, only to     have an upgrade stomp all over your changes. Debian solves this problem by marking such configuration files as conffiles. ^[55] When you upgrade a package, you'll be asked whether you want to keep your old configuration files or not. dh_installdeb(1) automatically flags any files under the /etc directory as conffiles, so if your program only has conffiles     there you do not need to specify them in this file. For most package types, the only place conffiles should ever be is under / etc, and so this file doesn't need to exist. If your program uses configuration files but also rewrites them     on its own, it's best not to make them conffiles because dpkg will then prompt users to verify the changes all the time. If the program you're packaging requires every user to modify the     configuration files in the /etc directory, there are two popular ways to arrange for them to not be conffiles, keeping dpkg quiet. * Create a symlink under the /etc directory pointing to a file under the /var directory generated by the maintainer scripts.     * Create a file generated by the maintainer scripts under the / etc directory.     For information on maintainer scripts, see 第 5.19 节 “{pre,post} {inst,rm}”. 5.4. package.cron.* If your package requires regularly scheduled tasks to operate properly, you can use these files to set that up. You can set up     regular tasks that either happen hourly, daily, weekly, or monthly, or alternatively happen at any other time that you wish. The filenames are: * package.cron.hourly - Installed as /etc/cron.hourly/package; run once an hour. * package.cron.daily - Installed as /etc/cron.daily/package; run once a day.     * package.cron.weekly - Installed as /etc/cron.weekly/package; run once a week. * package.cron.monthly - Installed as /etc/cron.monthly/package : run once a month. * package.cron.d - Installed as /etc/cron.d/package: for any other time.     Most of these files are shell scripts, with the exception of package.cron.d which follows the format of crontab(5).     No explicit cron.* file is needed to set up log rotation; for that, see dh_installlogrotate(1) and logrotate(8). 5.5. dirs This file specifies any directories which we need but which are     not created by the normal installation procedure (make install DESTDIR=... invoked by dh_auto_install). This generally means there is a problem with the Makefile.     Files listed in an install file don't need their directories created first. See 第 5.11 节 “install”. It is best to try to run the installation first and only use this     if you run into trouble. There is no preceding slash on the directory names listed in the dirs file. 5.6. package.doc-base If your package has documentation other than manual and info     pages, you should use the doc-base file to register it, so the user can find it with e.g. dhelp(1), dwww(1), or doccentral(1).     这通常包括 HTML、PS 和 PDF 文件，放置在 /usr/share/doc/ packagename/。     This is what gentoo's doc-base file gentoo.doc-base looks like: 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 For information on the file format, see install-docs(8) and the     Debian doc-base Manual at the local copy /usr/share/doc/doc-base/ doc-base.html/index.html provided by the doc-base package.     关于安装附加文档的更多信息，查看第 3.3 节 “Installation of files to their destination”。 5.7. docs     这个文件制定了我们使用 dh_installdocs(1) 安装到临时目录的文件名。     默认情况下它会加入代码目录顶层的所有名为 BUGS、README*、TODO 等的 文件。     For gentoo, some other files are also included: BUGS CONFIG-CHANGES CREDITS     NEWS README README.gtkrc TODO 5.8. emacsen-*     如果你的软件包提供可以在安装时编译为字节码的 Emacs 文件，你可以使 用这些文件设置。     它们会被 dh_installemacsen(1) 安装到临时目录。     如果你不需要这些，就删除它们。 5.9. package.examples     dh_installexamples(1) 会将列出的文件和目录作为示例文件安装。 5.10. package.init and package.default If your package is a daemon that needs to be run at system     start-up, you've obviously disregarded my initial recommendation, haven't you? :-) The package.init file is installed as the /etc/init.d/package script which starts and stops the daemon. Its fairly generic skeleton template is provided by the dh_make command as     init.d.ex. You'll likely have to rename and edit it, a lot, while making sure to provide Linux Standard Base (http:// www.linuxfoundation.org/collaborate/workgroups/lsb) (LSB) compliant headers. It gets installed into the temporary directory by dh_installinit(1). The package.default file will be installed as /etc/default/ package. This file sets defaults that are sourced by the init script. This package.default file is most often used to disable     running a daemon, or to set some default flags or timeouts. If your init script has certain configurable features, you can set them in the package.default file, instead of in the init script itself. If your upstream program provides a file for the init script, you can either use it or not. If you don't use their init script then     create a new one in package.init. However if the upstream init script looks fine and installs in the right place you still need to set up the rc* symlinks. To do this you will need to override dh_installinit in the rules file with the following lines:     override_dh_installinit: dh_installinit --onlyscripts     如果你不需要这些，就删除它们。 5.11. install If there are files that need to be installed into your package but your standard make install won't do it, put the filenames and     destinations into this install file. They are installed by dh_install(1).^[56] You should first check there is not a more specific tool to use. For example, documents should be in the docs file and not in this one. This install file has one line per file installed, with the name of the file (relative to the top build directory) then a space     then the installation directory (relative to the install directory). One example of where this is used is if a binary src/ bar is left uninstalled; the install file might look like:     src/bar usr/bin     This means when this package is installed, there will be an executable command /usr/bin/bar. Alternatively, this install can have the name of the file only without the installation directory when the relative directory     path does not change. This format is usually used for a large package that splits the output of its build into multiple binary packages using package-1.install, package-2.install, etc. The dh_install command will fall back to looking in debian/tmp     for files, if it doesn't find them in the current directory (or wherever you've told it to look using --sourcedir). 5.12. package.info     If your package has info pages, you should install them using dh_installinfo(1) by listing them in a package.info file. 5.13. package.links If you need to create additional symlinks in package build     directories as package maintainer, you should install them using dh_link(1) by listing their full paths of source and destination files in a package.links file. 5.14. {package.,source/}lintian-overrides If lintian reports an erroneous diagnostic for a case where Debian policy allows exceptions to some rule, you can use package     .lintian-overrides or source/lintian-overrides to quieten it. Please read Lintian User's Manual (/usr/share/doc/lintian/ lintian.html/index.html) and refrain from abusing this. package.lintian-overrides is for the binary package named package     and is installed into usr/share/lintian/overrides/package by the dh_lintian command.     source/lintian-overrides 是针对源代码包的，不会安装。 5.15. manpage.* Your program(s) should have a manual page. If they don't, you should create them. The dh_make command creates some template     files for manual pages. These need to be copied and edited for each command missing its manual page. Please make sure to remove unused templates. 5.15.1. manpage.1.ex     man 手册页通常是使用 nroff(1) 的格式编写的。manpage.1.ex 模板也是 使用 nroff 格式的。参看 man(7) 手册页来简要了解如何编辑这个文件。 The final manual page file name should give the name of the program it is documenting, so we will rename it from manpage to     gentoo. The file name also includes .1 as the first suffix, which means it's a manual page for a user command. Be sure to verify that this section is indeed the correct one. Here's a short list of manual page sections: +---------------------------------------------------------------+ |Section|Description |Notes | |-------+--------------------+----------------------------------| |1 |User command |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 |Games or other frivolous programs | |-------+--------------------+----------------------------------| |7 |Macro packages |Such as man macros | |-------+--------------------+----------------------------------| |8 |System |Programs typically only run by | | |administration |root | |-------+--------------------+----------------------------------| |9 |Kernel routines |Non-standard calls and internals | +---------------------------------------------------------------+ So gentoo's man page should be called gentoo.1. If there was no     gentoo.1 man page in the original source, you should create it by renaming the manpage.1.ex template to gentoo.1 and editing it using information from the example and from the upstream docs.     You can use the help2man command to generate a man page out of the --help and --version output of each program, too. ^[57] 5.15.2. manpage.sgml.ex     如果你希望使用 SGML 而非 nroff 格式编写 man 手册页，可以使用 manpage.sgml.ex 模板。如果你要这样，需要进行以下步骤： * 重命名文件为类似 gentoo.sgml 的名称。 * 安装 docbook-to-man 软件包。 * add docbook-to-man to the Build-Depends line in the control     file * add an override_dh_auto_build target to your rules file: override_dh_auto_build: docbook-to-man debian/gentoo.sgml > debian/gentoo.1 dh_auto_build 5.15.3. manpage.xml.ex     如果你希望使用XML 而非 SGML，可以使用 manpage.xml.ex 模板。如果你 要这样，需要进行以下步骤： * 重命名源文件为类似 gentoo.1.xml 的名称。 * 安装 docbook-xsl 软件包和一个 XSLT 处理器，例如 xsltproc (推荐)。 * add the docbook-xsl, docbook-xml, and xsltproc packages to the Build-Depends line in the control file * add an override_dh_auto_build target to your rules file:     override_dh_auto_build: xsltproc --nonet \ --param make.year.ranges 1 \ --param make.single.year.ranges 1 \ --param man.charmap.use.subset 0 \ -o debian/ \ http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl\ debian/gentoo.1.xml dh_auto_build 5.16. package.manpages     If your package has manual pages, you should install them using dh_installman(1) by listing them in a package.manpages file.     To install docs/gentoo.1 as a manpage for the gentoo package, create a gentoo.manpages file as follows.     docs/gentoo.1 5.17. menu X Windows 系统用户通常有窗口管理器，并且带有可定制的菜单用于启动     程序。如果他们安装了 Debian 的 menu 软件包，整个系统中所有已安装 软件的一系列菜单将会被自动创建。     Here's the default menu.ex file that dh_make created. ?package(gentoo):needs=X11|text|vc|wm \     section=Applications/see-menu-manual\ title=gentoo command=/usr/bin/gentoo     冒号后的第一个域是 needs，它指定了程序需要何种界面。修改此处为列 出的选项之一，例如 text 或 X11。     The next is the section that the menu and submenu entry should appear in. ^[58]     title 域是程序的名称，它可以用大写字母开头，只需保证它不要很长。     最后的 command 域是运行此程序时使用的命令。     我们把文件名修改为 menu，并修改其内容为： ?package(gentoo): needs=X11 \     section=Applications/Tools \ title=Gentoo command=gentoo You can also add other fields like longtitle, icon, hints etc.     See dh_installmenu(1), menufile(5), update-menus(1), and The Debian Menu sub-policy (http://www.debian.org/doc/ packaging-manuals/menu-policy/) for more information. 5.18. NEWS     dh_installchangelogs(1) 命令会安装这个文件。 5.19. {pre,post}{inst,rm} These postinst, preinst, postrm, and prerm files ^[59] are called     maintainer scripts. They are scripts which are put in the control area of the package and run by dpkg when your package is installed, upgraded, or removed. As a novice maintainer, you should avoid any manual editing of maintainer scripts because they are problematic. For more     information refer to the Debian Policy Manual, 6 "Package maintainer scripts and installation procedure" (http:// www.debian.org/doc/debian-policy/ch-maintainerscripts.html) , and take a look at the example files provided by dh_make. If you did not listen to me and have created custom maintainer     scripts for a package, you should make sure to test them not only for install and upgrade but also for remove and purge. Upgrades to the new version should be silent and non-intrusive     (existing users should not notice the upgrade except by discovering that old bugs have been fixed and perhaps that there are new features). When the upgrade is necessarily intrusive (eg., config files scattered through various home directories with totally different structure), you may consider as the last resort switching the     package to a safe fallback state (e.g., disabling a service) and providing the proper documentation required by policy (README.Debian and NEWS.Debian). Don't bother the user with debconf notes invoked from these maintainer scripts for upgrades. The ucf package provides a conffile-like handling infrastructure     to preserve user changes for files that may not be labeled as conffiles such as those managed by the maintainer scripts. This should minimize issues associated with them. These maintainer scripts are among the Debian enhancements that     explain why people choose Debian. You must be very careful not to turn them into a source of annoyance. 5.20. package.symbols Packaging of library is not easy for a novice maintainer and     should be avoided. Having said it, if your package has libraries, you should have debian/package.symbols files. See 第 A.2 节 “Managing debian/package.symbols”. 5.21. TODO     dh_installdocs(1) 命令会安装这个文件。 5.22. watch The watch file format is documented in the uscan(1) manpage. The watch file configures the uscan program (in the devscripts     package) to watch the site where you originally got the source from. This is also used by the Debian External Health Status (DEHS) (http://wiki.debian.org/DEHS) service.     Here are its contents: # watch control file for uscan     version=3 http://sf.net/gentoo/gentoo-(.+)\.tar\.gz debian uupdate Normally with a watch file, the URL at http://sf.net/gentoo is downloaded and searched for links of the form . The basename (just the part after the final /) of each linked URL is     compared against the Perl regular expression pattern (see perlre (1)) gentoo-(.+)\.tar\.gz. Out of the files that match, the one with the greatest version number is downloaded and the uupdate program is run to create an updated source tree. Although this is true for other sites, the SourceForge download service at http://sf.net (http://sf.net) is an exception. When the watch file has an URL matching the Perl regexp ^http://sf \.net/, the uscan program replaces it with http://qa.debian.org/     watch/sf.php/ and then applies this rule. The URL redirector service at http://qa.debian.org/ (http://qa.debian.org/) is designed to offer a stable redirect service to the desired file for any watch pattern of the form http://sf.net/project/tar-name- (.+)\.tar\.gz. This solves issues related to periodically changing SourceForge URLs. 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。这些修改会在解压源代码包时自动应用。^[60] Debian 修改保存于 debian.tar.gz 归档文件，其中包含了整个 debian 目录。这 个新格式支持直接添加例如 PNG 图标等的二进制文件。^[61] dpkg-source 解压 3.0 (quilt) 格式的源码包时会自动应用所有列于     debian/patches/series 的补丁。你可以使用 --skip-patches 选项避免 在解压后自动应用补丁。 5.24. source/local-options 如果你希望使用版本控制系统(VCS)时，你可以创建一个分支(例如叫做 upstream) 来跟踪上游代码，和另一个分支(对于 Git 而言典型的是     master 分支)来跟踪你的 Debian 软件包。对于后者，通常会将未应用补 丁的上游代码和你的 debian/* 文件放在一起以便容易合并上游的新代码 。 After you build a package, the source is normally left patched. You need to unpatch it manually by running dquilt pop -a before committing to the master branch. You can automate this by adding     the optional debian/source/local-options file containing unapply-patches. This file is not included in the generated source package and changes the local build behavior only. This file may contain abort-on-upstream-changes, too (see dpkg-source (1)).     unapply-patches abort-on-upstream-changes 5.25. source/options The autogenerated files in the source tree can be quite annoying     for packaging since they generate meaningless large patch files. There are custom modules such as dh_autoreconf to ease this problem as described in 第 4.4.3 节 “定制 rules 文件”. You can provide a Perl regular expression to the     --extend-diff-ignore option argument of dpkg-source(1) to ignore changes made to the autogenerated files while creating the source package. As a general solution to address this problem of the autogenerated files, you can store such a dpkg-source option     argument in the source/options file of the source package. The following will skip creating patch files for config.sub, config.guess, and Makefile.     extend-diff-ignore = "(^|/)(config\.sub|config\.guess|Makefile)$" 5.26. patches/* The old 1.0 source format created a single large diff.gz file containing package maintenance files in debian and patch files     for the source. Such a package is a bit cumbersome to inspect and understand for each source tree modification later. This is not so nice. The newer 3.0 (quilt) source format stores patches in debian/ patches/* files using the quilt command. These patches and other package data which are all contained under the debian directory     are packaged as the debian.tar.gz file. Since the dpkg-source command can handle quilt formatted patch data in the 3.0 (quilt) source without the quilt package, it does not need a Build-Depends on quilt. ^[62] The quilt command is explained in quilt(1). It records modifications to the source as a stack of -p1 patch files in the     debian/patches directory and the source tree is untouched outside of the debian directory. The order of these patches is recorded in the debian/patches/series file. You can apply (=push), un-apply (=pop), and refresh patches easily. ^[63]     For 第 3 章修改源代码, we created three patches in debian/ patches. Since Debian patches are located in debian/patches, please make     sure to set up the dquilt command properly as described in 第  3.1 节 “Setting up quilt”. When anyone (including yourself) provides a patch foo.patch to     the source later, modifying a 3.0 (quilt) source package is quite simple: $ dpkg-source -x gentoo_0.9.12.dsc $ cd gentoo-0.9.12 $ dquilt import ../foo.patch     $ dquilt push $ dquilt refresh $ dquilt header -e ... describe patch The patches stored in the newer 3.0 (quilt) source format must be     fuzz free. You can ensure this with dquilt pop -a; while dquilt push; do dquilt refresh; done. -------------- ^[54] In this chapter, files in the debian directory are referred     to without the leading debian/ for simplicity whenever the meaning is obvious. ^[55] See dpkg(1) and Debian Policy Manual, "D.2.5 Conffiles"     (http://www.debian.org/doc/debian-policy/ ap-pkg-controlfields.html#s-pkg-f-Conffiles) .     ^[56] 这取代了已经废弃的 dh_movefiles(1) 命令，它本是用 files 文 件所配置的。 ^[57] Note that help2man's placeholder man page will claim that     more detailed documentation is available in the info system. If the command is missing an info page, you should manually edit the man page created by the help2man command. ^[58] The current list of sections is in The Debian Menu     sub-policy 2.1 "Preferred menu structure" (http://www.debian.org/ doc/packaging-manuals/menu-policy/ch2.html#s2.1) . There was a major reorganization of menu structure for squeeze. ^[59] Despite this use of the bash shorthand expression     {pre,post}{inst,rm} to indicate these filenames, you should use pure POSIX syntax for these maintainer scripts for compatibility with dash as the system shell. ^[60] See DebSrc3.0 (http://wiki.debian.org/Projects/DebSrc3.0)     for a summary on the switch to the new 3.0 (quilt) and 3.0 (native) source formats.     ^[61] 实际上新格式还支持多个上游 tarball 和更多的压缩方法，但这已 超出本文档讲述的范围。 ^[62] Several methods of patch set maintenance have been proposed and are in use for Debian packages. The quilt system is the     preferred maintenance system in use. Others include dpatch, dbs, and cdbs. Many of these keep such patches as debian/patches/* files. ^[63] If you are asking a sponsor to upload your package, this     kind of clear separation and documentation of your changes is very important to expedite the package review by your sponsor. 第 6 章 构建软件包     现在我们已经为构建软件包做好了准备。 6.1. 完整的(重)构建     In order to perform a complete (re)build of a package properly, you need to make sure you have installed * build-essential 软件包；     * 列于 Build-Depends 域的软件包(参看第 4.1 节 “control”)； * 列于 Build-Depends-indep 域的软件包(参看第 4.1 节 “control”) 。     然后在源代码目录中执行以下命令：     $ dpkg-buildpackage     这样会自动完成所有从源代码包构建二进制包的工作，包括： * 清理源代码树(debian/rules clean) * 构建源代码包(dpkg-source -b) * 构建程序(debian/rules build)     * 构建二进制包(fakeroot debian/rules binary) * 使用 gpg 签署 .dsc 文件 * 使用 dpkg-genchanges 和 gpg 创建并签署上传用的 .changes 文件 The only input that will be required of you is your GPG secret     pass phrase, twice. ^[64] If you are building Debian packages only for your own local use, you can skip promptings for the GPG signatures on the .dsc file and the .changes file like this:     $ dpkg-buildpackage -us -uc For a non-native Debian package, e.g., gentoo, you will see the     following files in the parent directory (~/gentoo) after building packages: * gentoo_0.9.12.orig.tar.gz This is the original upstream source code tarball, merely renamed to the above so that it adheres to the Debian standard. Note that this was created initially by the 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 This compressed tarball contains your debian directory contents. Each and every addition you made to the original source code is stored as a quilt patch in debian/patches. 如果其他人想要重新构建你的软件包，他们可以使用以上三个文件很 容易地完成。只需复制三个文件，再运行 dpkg-source -x     gentoo_0.9.12-1.dsc。 ^[65] * gentoo_0.9.12-1_i386.deb 这是你的二进制包，可以使用 dpkg 程序安装或卸载它，就像其他软 件包一样。 * gentoo_0.9.12-1_i386.changes This file describes all the changes made in the current package revision; it is used by the Debian FTP archive maintenance programs to install the binary and source packages. It is partly generated from the changelog file and the .dsc file. This file is GPG signed, so that people can be sure that it's really yours. As you keep working on the package, its behavior will change and new features will be added. People downloading your package can look at this file and quickly see what has changed. Debian archive maintenance programs will also post the contents of this file to the debian-devel-changes@lists.debian.org (http:// lists.debian.org/debian-devel-changes/) mailing list. The long strings of numbers in the .dsc and .changes files are SHA1/SHA256 checksums for the files mentioned. Anyone downloading     your files can test them with sha1sum(1) or sha256sum(1) and if the numbers don't match, they'll know the file is corrupt or has been tampered with.     For a native Debian package, e.g., mypackage, you will see the following files in the parent directory after building packages: * mypackage_1.0.tar.gz This is the source code tarball created from the mypackage-1.0 directory by the dpkg-source command. (Its suffix is not orig.tar.gz.) * mypackage_1.0.dsc This is a summary of the contents of the source code as in the non-native Debian package. (There is no Debian revision.)     * mypackage_1.0_i386.deb This is your completed binary package as in the non-native Debian package. (There is no Debian revision.) * mypackage_1.0_i386.changes This file describes all the changes made in the current package version as in the non-native Debian package. (There is no Debian revision.) 6.2. 自动编译系统 Debian supports many ports (http://www.debian.org/ports/) with the autobuilder network (http://www.debian.org/devel/buildd/) running buildd daemons on computers of many different     architectures. Although you do not need to do this yourself, you should be aware of what will happen to your packages. Let's look into roughly how they rebuild your packages for multiple architectures. ^[66]     For Architecture: any packages, the autobuilder system performs a rebuild. It ensures the installation of * build-essential 软件包；     * 列于 Build-Depends 域的软件包(参看第 4.1 节 “control”)。     然后在源代码目录中执行以下命令：     $ dpkg-buildpackage -B     这样会自动完成从源代码包构建平台依赖二进制包的工作，包括： * 清理源代码树(debian/rules clean) * 构建程序(debian/rules build)     * 构建平台依赖二进制包(fakeroot debian/rules binary-arch) * 使用 gpg 签署 .dsc 文件 * 使用 dpkg-genchanges 和 gpg 创建并签署上传用的 .changes 文件     这就是你看到你的软件包在其他平台上可用的原因。 Although packages listed in the Build-Depends-Indep field are required to be installed for our normal packaging work (see 第  6.1 节 “完整的(重)构建”), they are not required to be installed for the autobuilder system since it builds only architecture     dependent binary packages. ^[67] This distinction between normal packaging and autobuilding procedures is what dictates whether you should record such required packages in the Build-Depends or Build-Depends-Indep fields of the debian/control file (see 第  4.1 节 “control”). 6.3. debuild 命令     You can automate the dpkg-buildpackage command's package build process further with the debuild command. See debuild(1). Customization of the debuild command can be done through /etc/     devscripts.conf or ~/.devscripts. I would suggest at least the following items:     DEBSIGN_KEYID=Your_GPG_keyID DEBUILD_LINTIAN_OPTS=-i -I --show-overrides With these, packages are signed by your specified GPG key ID     (good for sponsoring packages) and checked in detail by the lintian command.     Cleaning the source and rebuilding the package from your user account is as simple as:     $ debuild Here, if you are building Debian packages only for your own local     use, you can skip promptings for the GPG signatures on the .dsc file and the .changes file like this:     $ debuild -us -uc     You can clean the source tree as simply as:     $ debuild clean 6.4. pbuilder 软件包 For a clean room (chroot) build environment to verify the build dependencies, the pbuilder package is very useful. ^[68] This     ensures a clean build from the source under the sid auto-builder for different architectures and avoids a severity serious FTBFS (Fails To Build From Source) bug which is always in the RC (release critical) category. ^[69]     Let's customize the pbuilder package as follows: * setting the /var/cache/pbuilder/result directory writable by for your user account. * creating a directory, e.g. /var/cache/pbuilder/hooks, writable by the user, to place hook scripts in.     * configuring ~/.pbuilderrc or /etc/pbuilderrc to include the followsing. AUTO_DEBSIGN=${AUTO_DEBSIGN:-yes} HOOKDIR=/var/cache/pbuilder/hooks     这使你可以使用 ~/.gnupg/ 目录中的 GPG 私钥签署生成的软件包。     First let's initialize the local pbuilder chroot system as follows.     $ sudo pbuilder create If you already have a completed source package, issue the     following commands in the directory where the foo.orig.tar.gz, foo.debian.tar.gz, and foo.dsc files exist to update the local pbuilder chroot system and to build binary packages in it.     $ sudo pbuilder --update $ sudo pbuilder --build foo_version.dsc     The newly built packages without the GPG signatures will be located in /var/cache/pbuilder/result/ with non-root ownership.     The GPG signatures on the .dsc file and the .changes file can be generated as: $ cd /var/cache/pbuilder/result/     $ debsign foo_version.dsc $ debsign foo_version_arch.changes If you have an updated source tree but have not generated the     matching source package, issue the following commands in the source directory where the debian directory exists, instead.     $ sudo pbuilder --update $ pdebuild Here, if you are building Debian packages only for your local     use, you can skip promptings for the GPG signatures on the .dsc file and the .changes file as:     $ AUTO_DEBSIGN=no pdebuild 你可以使用 pbuilder --login --save-after-login 命令登录到这个     chroot 环境中并按照需要对其进行配置。通过 ^D (Control-D)离开这个 shell 时环境会被保存。     最新版的 lintian 命令可以通过设置钩子脚本 /var/cache/pbuilder/ hooks/B90lintian 在 chroot 环境中运行。脚本内容如下：^[70] #!/bin/sh set -e install_packages() { apt-get -y --force-yes install "$@" }     install_packages lintian echo "+++ lintian output +++" su -c "lintian -i -I --show-overrides /tmp/buildd/*.changes" - pbuilder # use this version if you don't want lintian to fail the build #su -c "lintian -i -I --show-overrides /tmp/buildd/*.changes; :" - pbuilder echo "+++ end of lintian output +++" You need to have access to the latest sid environment to build packages properly for sid. In practice, sid may be experiencing     issues which makes it undesirable for you to migrate your whole system. The pbuilder package can help you to cope with this kind of situation. You may need to update your stable packages after their release for stable-proposed-updates, stable/updates, etc. ^[71] For such     occasions, the fact you may be running a sid system is not a good enough excuse for failing to update them promptly. The pbuilder package can help you to access environments of almost any Debian derivative distribution of the same architecture. See http://www.netfort.gr.jp/~dancer/software/pbuilder.html     (http://www.netfort.gr.jp/~dancer/software/pbuilder.html) , pdebuild(1), pbuilderrc(5), and pbuilder(8). 6.5. git-buildpackage 和相似命令 If your upstream uses a source code management system (VCS) ^[72] to maintain their code, you should consider using it as well.     This makes merging and cherry-picking upstream patches much easier. There are several specialized wrapper script packages for Debian package building for each VCS. * git-buildpackage: a suite to help with Debian packages in Git repositories.     * svn-buildpackage：帮助维护 Subversion 仓库中软件包的程序。 * cvs-buildpackage: a set of Debian package scripts for CVS source trees. Use of git-buildpackage is becoming quite popular for Debian     Developers to manage Debian packages with the Git server on alioth.debian.org (http://alioth.debian.org/) . ^[73] This package offers many commands to automate packaging activities. * git-import-dsc(1): import previous Debian package to a Git repository. * git-import-orig(1): import new upstream tar to a Git repository.     * git-dch(1): generate the Debian changelog from Git commit messages. * git-buildpackage(1): build Debian packages from a Git repository. * git-pbuilder(1): build Debian packages from a Git repository using pbuilder/cowbuilder.     These commands use 3 branches to track packaging activity. * main for Debian package source tree.     * upstream for upstream source tree. * pristine-tar for upstream tarball generated by the --pristine-tar option.^[74]     You can configure git-buildpackage with ~/.gbp.conf. See gbp.conf (5). ^[75] 6.6. 快速重构建 With a large package, you may not want to rebuild from scratch     every time while you're tuning details in debian/rules. For testing purposes, you can make a .deb file without rebuilding the upstream sources like this^[76]:     $ fakeroot debian/rules binary     Or simply do the following to see if it builds or not:     $ fakeroot debian/rules build     一旦完成了调试，记住要按照前面所的正常过程重构建你的软件包。你可 能无法正常上传用此种方法构建的 .deb 文件。 -------------- ^[64] This GPG key must be signed by a Debian developer to get connected to the web of trust and must be registered to the Debian keyring (http://keyring.debian.org) . This enables your     uploaded packages to be accepted to the Debian archives. See Creating a new GPG key (http://keyring.debian.org/ creating-key.html) and Debian Wiki on Keysigning (http:// wiki.debian.org/Keysigning ) . ^[65] You can avoid applying quilt patches in the 3.0 (quilt)     source format at the end of the extraction with the --skip-patches option. Alternatively, you can run dquilt pop -a after normal operation. ^[66] The actual autobuilder system involves much more     complicated schemes than the one documented here. Such details are beyond the scope of this document. ^[67] Unlike under the pbuilder package, the chroot environment     under the sbuild package used by the autobuilder system does not enforce the use of a minimal system and may have many leftover packages installed. ^[68] Since the pbuilder package is still evolving, you should     check the actual configuration situation by consulting the latest official documentation.     ^[69] See http://buildd.debian.org/ (http://buildd.debian.org/) for more on Debian package auto-building. ^[70] This assumes HOOKDIR=/var/cache/pbuilder/hooks. You can     find many examples of hook scripts in the /usr/share/doc/pbuilder /examples directory.     ^[71] 升级你的 stable 软件包有规定限制。     ^[72] See Version control systems (http://www.debian.org/doc/ manuals/debian-reference/ch10#_version_control_systems) for more. ^[73] Debian wiki Alioth (http://wiki.debian.org/Alioth)     documents how to use the alioth.debian.org (http:// alioth.debian.org/) service. ^[74] The --pristine-tar option invokes the pristine-tar command which can regenerate an exact copy of a pristine upstream tarball     using only a small binary delta file and the contents of the tarball, which are typically kept in an upstream branch in the VCS.     ^[75] Here are some web resources available for advanced audiences. * Building Debian Packages with git-buildpackage (/usr/share/ doc/git-buildpackage/manual-html/gbp.html) * debian packages in git (https://honk.sigxcpu.org/piki/ development/debian_packages_in_git/) * Using Git for Debian Packaging (http://www.eyrie.org/~eagle/     notes/debian/git.html) * git-dpm: Debian packages in Git manager (http:// git-dpm.alioth.debian.org/) * Using TopGit to generate quilt series for Debian packaging (http://git.debian.org/?p=collab-maint/topgit.git;a= blob_plain;f=debian/HOWTO-tg2quilt;hb=HEAD)     ^[76] 常规情形下被配置好的环境变量在此时不会被自动设置。永远不要 将使用这个快速方法构建的软件包上传到任何地方。 第 7 章 检查软件包中的错误     There are some techniques you should know for checking a package for errors before uploading it to the public archives. It's also a good idea to carry out testing on a machine other     than your own. You must watch closely for any warnings or errors for all the tests described here. 7.1. Suspicious changes If you find a new autogenerated patch file such as debian-changes-* in the debian/patches directory after building your non-native Debian package in 3.0 (quilt) format, chances are     you changed some files by accident or the build script modified the upstream source. If it is your mistake, fix it. If it is caused by the build script, fix the root cause with dh-autoreconf as in 第 4.4.3 节 “定制 rules 文件” or work around it with source /options as in 第 5.25 节 “source/options”. 7.2. Verifying a package's installation You must test your package for whether it installs without     problem. The debi(1) command helps you to test installing all the generated binary packages.     $ sudo debi gentoo_0.9.12-1_i386.changes To prevent installation problem on different systems, you must make sure that there are no filenames conflicting with other existing packages, using the Contents-i386 file downloaded from the Debian archive. The apt-file command may be handy for this     task. If there are collisions, please take action to avoid this real problem, whether by renaming the file, moving a common file to a separate package that multiple packages can depend on, using the alternatives mechanism (see update-alternatives(1)) in coordination with the maintainers of other affected packages, or declaring a Conflicts relationship in the debian/control file. 7.3. Verifying a package's maintainer scripts All maintainer scripts (that is, preinst, prerm, postinst, and postrm files) are hard to write correctly unless they are     auto-generated by the debhelper programs. So do not use them if you are a novice maintainer (see 第 5.19 节 “{pre,post}{inst,rm}” ). If the package makes use of these non-trivial maintainer scripts, be sure to test not only for install but also for remove, purge,     and upgrade processes. Many maintainer script bugs show up when packages are removed or purged. Use the dpkg command as follows to test them. $ sudo dpkg -r gentoo     $ sudo dpkg -P gentoo $ sudo dpkg -i gentoo_version-revision_i386.deb     整个测试过程应按照以下序列操作： * 如果可能，安装前一个版本的软件包； * 从前一个版本升级软件包； * 降级软件包到前一个版本(可选)； * 彻底删除该软件包；     * 全新安装该软件包； * 卸载该软件包； * 再次安装该软件包。 * 彻底删除该软件包；     如果这是你的第一个软件包，你应该使用其他版本号创建一个测试用的软 件包来完成升级测试，这样可以避免将来的问题。 请牢记如果你的软件包已经在以往版本的 Debian 中发布，人们通常会从     最近发布的 Debian 发布里的版本升级，所以也要测试从那个版本升级到 当前的版本。     Although downgrading is not officially supported, supporting it is a friendly gesture. 7.4. Using lintian     使用 lintian(1) 检查你的 .changes 文件。lintian 命令会运行很多测 试脚本来检查常见的打包错误。^[77]     $ lintian -i -I --show-overrides gentoo_0.9.12-1_i386.changes Of course, replace the filename with the name of the .changes     file generated for your package. The output of the lintian command uses the following flags. * E: for error; a sure policy violation or packaging error. * W: for warning; a possible policy violation or packaging error.     * I: for info; information on certain aspects of packaging. * N: 代表注释：帮助你调试的详细信息。 * O: 代表已覆盖：一个被 lintian-overrides 文件覆盖的信息，但由 于使用 --show-overrides 选项而显示。 When you see warnings, tune the package to avoid them or verify     that the warnings are spurious. If spurious, set up lintian-overrides files as described in 第 5.14 节 “{package .,source/}lintian-overrides”. Note that you can build the package with dpkg-buildpackage and     run lintian on it in one command, if you use debuild(1) or pdebuild(1). 7.5. The debc command     You can list files in the binary Debian package with the debc(1) command.     $ debc package.changes 7.6. The debdiff command     你可以使用 debdiff(1) 命令比较两个 Debian 源代码包的内容。     $ debdiff old-package.dsc new-package.dsc     你还可以使用 debdiff(1) 命令比较两个 Debian 二进制包的文件列表。     $ debdiff old-package.changes new-package.changes These are useful to identify what has been changed in the source     packages and to check for inadvertent changes made when updating binary packages, such as unintentionally misplacing or removing files. 7.7. The interdiff command     你可以使用 interdiff(1) 命令比较两个 diff.gz 文件。这对于更新使用 旧的 1.0 源代码格式的软件包时，检查是否有意外的变更非常有用。     $ interdiff -z old-package.diff.gz new-package.diff.gz The new 3.0 source format stores changes in multiple patch files     as described in 第 5.26 节 “patches/*”. You can trace changes of each debian/patches/* file using interdiff, too. 7.8. The mc command 很多文件检查操作可以通过使用类似 mc(1) 的文件管理器来完成，它可以     帮助你直接查看 *.deb 文件的内容，除此之外还可以用于 *.udeb、 *.debian.tar.gz、*.diff.gz 和 *.orig.tar.gz 文件。 Be on the lookout for extra unneeded files or zero length files,     both in the binary and source package. Often cruft doesn't get cleaned up properly; adjust your rules file to compensate for this. -------------- ^[77] 如果你按照第 6.3 节 “debuild 命令” 中的叙述定义了 /etc/     devscripts.conf 或 ~/.devscripts 文件，就不需要再添加 lintian 选 项 -i -I --show-overrides。 第 8 章 上传软件包     Now that you have tested your new package thoroughly, you want to release it to a public archive to share it. 8.1. 上传到 Debian 仓库 Once you become an official developer, ^[78] you can upload the     package to the Debian archive. ^[79] You can do this manually, but it's easier to use the existing automated tools, like dupload (1) or dput(1). We'll describe how it's done with dupload. ^[80] 首先需要设置 dupload 的配置文件。你既可以编辑系统级的 /etc/     dupload.conf 文件，也可以使用自己的 ~/.dupload.conf 文件覆盖一些 需要修改的设置。     你可以阅读 dupload.conf(5) man 手册页来了解各选项的含义。 The $default_host option determines which of the upload queues     will be used by default. anonymous-ftp-master is the primary one, but it's possible that you will want to use another one. ^[81]     While connected to the Internet, you can upload your package as follows:     $ dupload gentoo_0.9.12-1_i386.changes dupload checks that the SHA1/SHA256 file checksums match those     listed in the .changes file. If they do not match, it will warn you to rebuild it as described in 第 6.1 节 “完整的(重)构建” so it can be properly uploaded. If you encounter an upload problem at ftp://ftp.upload.debian.org     /pub/UploadQueue/ (ftp://ftp.upload.debian.org/pub/UploadQueue/) , you can fix this by manually uploading a GPG-signed *.commands file to there with ftp. ^[82] For example, using hello.commands: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Uploader: Foo Bar Commands: rm hello_1.0-1_i386.deb     mv hello_1.0-1.dsx hello_1.0-1.dsc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) [...] -----END PGP SIGNATURE----- 8.2. 在上传时包含 orig.tar.gz 文件 When you first upload the package to the archive, you need to     include the original orig.tar.gz source, too. If the Debian revision number of this package is neither 1 nor 0, you must provide the dpkg-buildpackage option -sa.     For the dpkg-buildpackage command:     $ dpkg-buildpackage -sa     For the debuild command:     $ debuild -sa     For the pdebuild command:     $ pdebuild --debbuildopts -sa     On the other hand, the -sd option will force the exclusion of the original orig.tar.gz source. 8.3. 跳过的上传 If you created multiple entries in debian/changelog by skipping     uploads, you must create a proper *_.changes file which includes all changes from the last upload. This can be done by specifying the dpkg-buildpackage option -v with the version, e.g., 1.2.     For the dpkg-buildpackage command:     $ dpkg-buildpackage -v1.2     For the debuild command:     $ debuild -v1.2     For the pdebuild command:     $ pdebuild --debbuildopts "-v1.2" --------------     ^[78] See 第 1.1 节 “Debian 的社会驱动力”. ^[79] There are publicly accessible archives such as http:// mentors.debian.net/ (http://mentors.debian.net/) which work almost the same way as the Debian archive and provide an upload     area for non-DDs. You can set up an equivalent archive by yourself using the tools listed at http://wiki.debian.org/ HowToSetupADebianRepository (http://wiki.debian.org/ HowToSetupADebianRepository) . So this section is useful for non-DDs, too. ^[80] The dput package seems to come with more features and to be becoming more popular than the dupload package. It uses the file     /etc/dput for its global configuration and the file ~/.dput.cf for per-user configuration. It supports Ubuntu-related services out-of-the-box, too. ^[81] See Debian Developer's Reference 5.6. "Uploading a package"     (http://www.debian.org/doc/manuals/developers-reference/pkgs.html #upload) . ^[82] See ftp://ftp.upload.debian.org/pub/UploadQueue/README     (ftp://ftp.upload.debian.org/pub/UploadQueue/README) . Alternatively, you can use the dcut command from the dput package. 第 9 章 更新软件包     After you release a package, you will soon need to update it. 9.1. 新的 Debian 版本 Let's say that a bug report was filed against your package as #     654321, and it describes a problem that you can solve. Here's what you need to do to create a new Debian revision of the package. * 如果要将它记录于新的补丁中，这样做： o dquilt new bugname.patch to set the patch name; o dquilt add buggy-file to declare the file to be modified; o 修正软件包代码中的上游 Bug； o dquilt refresh to record it to bugname.patch; o dquilt header -e to add its description; * 如果是更新一个已存在的补丁，这样做： o dquilt pop foo.patch to recall the existing foo.patch; o 修正旧的 foo.patch 中的问题； o dquilt refresh to update foo.patch; o dquilt header -e to update its description; o while dquilt push; do dquilt refresh; done to apply all patches while removing fuzz;     * 在 Debian changelog 文件的顶部添加一个条目。例如可以使用 dch -i 或用 dch -v version-revision 来指定版本，然后用你喜欢的编 辑器插入信息。^[83] * Include a short description of the bug and the solution in the changelog entry, followed by Closes: #654321. That way, the bug report will be automagically closed by the archive maintenance software the moment your package gets accepted into the Debian archive. * 重复上述操作来修复更多的 Bug，并在需要的时候使用 dch 更新 Debian changelog 文件。 * Repeat what you did in 第 6.1 节 “完整的(重)构建” and 第 7 章 检查软件包中的错误. * Once you are satisfied, you should change the distribution value in changelog from UNRELEASED to the target distribution value unstable (or even experimental).^[84] * Upload the package as 第 8 章上传软件包. The difference is that this time, the original source archive won't be included, as it hasn't been changed and it already exists in the Debian archive. One tricky case can occur when you make a local package to experiment with the packaging before uploading the normal version to the official archive, e.g., 1.0.1-1. For smoother upgrades, it     is a good idea to create a changelog entry with a version string as 1.0.1-1~rc1. You may unclutter changelog by consolidating such local change entries into a single entry for the official package. See 第 2.6 节 “软件包名称和版本” for the order of version strings.     9.2. 检查新上游版本     When preparing packages of a new upstream release for the Debian archive, you must check the new upstream release, first.     Start by reading the upstream changelog, NEWS, and whatever other documentation they may have released with the new version.     You can then inspect changes between the old and new upstream sources as follows, watching out for anything suspicious.     $ diff -urN foo-oldversion foo-newversion Changes to some auto-generated files by Autotools such as missing, aclocal.m4, config.guess, config.h.in, config.sub,     configure, depcomp, install-sh, ltmain.sh, and Makefile.in may be ignored. You may delete them before running diff on the source for inspection. 9.3. 新上游版本 If a package foo is properly packaged in the newer 3.0 (native) or 3.0 (quilt) formats, packaging a new upstream version is     essentially moving the old debian directory to the new source. This can be done by running tar xvzf /path/to/foo_oldversion .debian.tar.gz in the new extracted source. ^[85] Of course, you need to do some obvious chores. * 创建一份上游源代码的副本，命名为 foo_newversion.orig.tar.gz * 使用 dch -v newversion-1 更新 Debian changelog 文件。 o Add an entry with New upstream release. o Describe concisely the changes in the new upstream     release that fix reported bugs and close those bugs by adding Closes: #bug_number. o Describe concisely the changes to the new upstream release by the maintainer that fix reported bugs and close those bugs by adding Closes: #bug_number. * while dquilt push; do dquilt refresh; done to apply all patches while removing fuzz.     如果补丁没有干净地被应用，检查原因(线索在 .rej 文件里)。 * If a patch you applied to the source was integrated into the upstream source, o dquilt delete to remove it. * 如果你的补丁与上游代码中的变更有冲突： o dquilt push -f to apply old patches while forcing rejects     as baz.rej. o Edit the baz file manually to bring about the intended effect of baz.rej. o dquilt refresh to update the patch. * Continue as usual with while dquilt push; do dquilt refresh; done.     这个过程可以通过使用 uupdate(1) 来更自动化地完成： $ apt-get source foo ... dpkg-source: info: extracting foo in foo-oldversion dpkg-source: info: unpacking foo_oldversion.orig.tar.gz dpkg-source: info: applying foo_oldversion-1.debian.tar.gz $ ls -F foo-oldversion/ foo_oldversion-1.debian.tar.gz     foo_oldversion-1.dsc foo_oldversion.orig.tar.gz $ wget http://example.org/foo/foo-newversion.tar.gz $ cd foo-oldversion $ uupdate -v newversion ../foo-newversion.tar.gz $ cd ../foo-newversion $ while dquilt push; do dquilt refresh; done $ dch ... document changes made 如果你按照第 5.22 节 “watch” 的叙述设置了 debian/watch 文件，你可     以跳过这个 wget 命令，转而在 foo-oldversion 目录中运行 uscan(1)， 且无需再执行 uupdate 命令。它会自动查找新的源代码、下载并运行 uupdate 命令。^[86]     重复第 6.1 节 “完整的(重)构建” 、第 7 章检查软件包中的错误和第 8  章上传软件包中的操作，即可发布此更新的软件包。 9.4. 更新打包风格 Updating the package style is not a required activity for the     update of a package. However, doing so lets you use the full capabilities of the modern debhelper system and the 3.0 source format. ^[87] * If you need to recreate deleted template files for any reason, you can run dh_make again in the same Debian package source tree with the --addmissing option. Then edit them appropriately. * If the package has not been updated to use the debhelper v7+ dh syntax for the debian/rules file, update it to use dh. Update the debian/control file accordingly. * If you want to update the rules file created with the Makefile inclusion mechanism of the Common Debian Build System (cdbs) to the dh syntax, see the following to understand its DEB_* configuration variables. o local copy of /usr/share/doc/cdbs/cdbs-doc.pdf.gz o The Common Debian Build System (CDBS), FOSDEM 2009 (http: //meetings-archive.debian.net/pub/debian-meetings/2009/ fosdem/slides/The_Common_Debian_Build_System_CDBS/)     * If you have a 1.0 source package without the foo.diff.gz file, you can update it to the newer 3.0 (native) source format by creating debian/source/format with 3.0 (native). The rest of the debian/* files can just be copied. * If you have a 1.0 source package with the foo.diff.gz file, you can update it to the newer 3.0 (quilt) source format by creating debian/source/format with 3.0 (quilt). The rest of the debian/* files can just be copied. Import the big.diff file generated by the command filterdiff -z -x '*/debian/*' foo.diff.gz > big.diff to your quilt system, if needed. ^[88] * If it was packaged using another patch system such as dpatch, dbs, or cdbs with -p0, -p1, or -p2, convert it to the quilt command using deb3 at http://bugs.debian.org/581186 (http:// bugs.debian.org/581186) . * If it was packaged with the dh command with the --with quilt option or with the dh_quilt_patch and dh_quilt_unpatch commands, remove these and make it use the newer 3.0 (native) source format.     You should check DEP - Debian Enhancement Proposals (http:// dep.debian.net/) and adopt ACCEPTED proposals.     You need to do the other tasks described in 第 9.3 节 “新上游版本 ”, too. 9.5. UTF-8 conversion     If upstream documents are encoded in old encoding schemes, converting them to UTF-8 is a good idea. * Use iconv(1) to convert encodings of plain text files. iconv -f latin1 -t utf8 foo_in.txt > foo_out.txt * Use w3m(1) to convert from HTML files to UTF-8 plain text     files. When you do this, make sure to execute it under UTF-8 locale. LC_ALL=C.UTF-8 w3m -o display_charset=UTF-8 \ -cols 70 -dump -no-graph -T text/html \ < foo_in.html > foo_out.txt 9.6. 对更新软件包的几点提示     以下是对更新软件包的几点提示。 * Preserve old changelog entries (sounds obvious, but there have been cases of people typing dch when they should have typed dch -i.) * 已存在的 Debian 修改需要被重新校验，去除上游已经接受的东西， 除非有必要的原因，还要记录尚未被上游接受的部分。 * 如果对编译系统作出了修改(希望你已经在检查上游变更时了解了这 些)，那么要在必要时更新 debian/rules 和 debian/control 编译依     赖关系。 * Check the Debian Bug Tracking System (BTS) (http:// www.debian.org/Bugs/) to see if someone has provided patches to bugs that are currently open. * Check the contents of the .changes file to make sure you are uploading to the correct distribution, the proper bug closures are listed in the Closes field, the Maintainer and Changed-By fields match, the file is GPG-signed, etc. --------------     ^[83] 要获得需要的日期格式，使用 LANG=C date -R。 ^[84] If you use the dch -r command to make this last change,     please make sure to save the changelog file explicitly by the editor. ^[85] 如果软件包 foo 是使用旧的 1.0 格式的，可以在新解压的源代码     目录里运行 zcat /path/to/foo_oldversion.diff.gz|patch -p1 来完成 。 ^[86] 如果 uscan 命令下载并更新了源代码，但没有运行 uupdate 命令     ，你应该修正 debian/watch 文件，使 URL 末尾后带有 debian uupdate 。 ^[87] If your sponsor or other maintainers object to updating the     existing packaging style, don't bother arguing. There are more important things to do.     ^[88] You can split big.diff into many small incremental patches using the splitdiff command. 附录 A. Advanced packaging Here are some hints and pointers for advanced packaging topics     which you are most likely to deal with. You are strongly advised to read all the references suggested here. A.1. Shared libraries     Before packaging shared libraries, you should read the following primary references in detail. * Debian Policy Manual, 8 "Shared libraries" (http:// www.debian.org/doc/debian-policy/ch-sharedlibs.html)     * Debian Policy Manual, 9.1.1 "File System Structure" (http:// www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs) * Debian Policy Manual, 10.2 "Libraries" (http://www.debian.org /doc/debian-policy/ch-files.html#s-libraries)     Here are some oversimplified hints for you to get started. * Shared libraries are ELF object files containing compiled code. * Shared libraries are distributed as *.so files. (Neither *.a files nor *.la files) * Shared libraries are mainly used to share common codes among multiple executables with the ld mechanism. * Shared libraries are sometimes used to provide multiple plugins to an executable with the dlopen mechanism. * Shared libraries export symbols which represent compiled objects such as variables, functions, and classes; and enables access to them from the linked executables. * The SONAME of a shared library libfoo.so.1: objdump -p libfoo .so.1 | grep SONAME ^[89] * The SONAME of a shared library usually matches the library file name (but not always). * The SONAME of shared libraries linked to /usr/bin/foo:     objdump -p /usr/bin/foo | grep NEEDED ^[90] * libfoo1: the library package for the shared library libfoo .so.1 with the SONAME ABI version 1.^[91] * The package maintainer scripts of the library package must call ldconfig under the specific circumstances to create the necessary symbolic links for the SONAME.^[92] * libfoo1-dbg: the debugging symbols package which contains the debugging symbols for the shared library package libfoo1. * libfoo-dev: the development package which contains the header files etc. for the shared library libfoo.so.1.^[93] * Debian package should not contain *.la Libtool archive files in general.^[94] * Debian package should not use RPATH in general.^[95] * Although it is somewhat outdated and is only a secondary reference, Debian Library Packaging Guide (http:// www.netfort.gr.jp/~dancer/column/libpkg-guide/ libpkg-guide.html) may still be useful. A.2. Managing debian/package.symbols When you package a shared library, you should create debian/ package.symbols file to manage the minimal version associated to     each symbol for backward-compatible ABI changes under the same SONAME of the library for the same shared library package name.^[ 96] You should read the following primary references in detail. * Debian Policy Manual, 8.6.3 "The symbols system" (http:// www.debian.org/doc/debian-policy/ch-sharedlibs.html# s-sharedlibs-symbols) ^[97] * dh_makeshlibs(1)     * dpkg-gensymbols(1) * dpkg-shlibdeps(1) * deb-symbols(5)     Here is a rough example to create the libfoo1 package to the upstream version 1.3 with the proper debian/libfoo1.symbols file. * Prepare the skeleton debianized source tree using the upstream libfoo-1.3.tar.gz file. o If this is the first packaging of the libfoo1 package, create the debian/libfoo1.symbols file with empty content. o If the previous upstream version 1.2 was packaged as the libfoo1 package with the proper debian/libfoo1.symbols in its source package, use it again. o If the previous upstream version 1.2 was not packaged with the debian/libfoo1.symbols, create it as the symbols file from all available binary packages of the same shared library package name containing the same SONAME of the library, for example, versions 1.1-1 and 1.2-1. ^[98] $ dpkg-deb -x libfoo1_1.1-1.deb libfoo1_1.1-1 $ dpkg-deb -x libfoo1_1.2-1.deb libfoo1_1.2-1 $ : > symbols $ dpkg-gensymbols -v1.1 -plibfoo1 -Plibfoo1_1.1-1 -Osymbols $ dpkg-gensymbols -v1.2 -plibfoo1 -Plibfoo1_1.2-1 -Osymbols * Make trial builds of the source tree with tools such as debuild and pdebuild. (If this fails due to missing symbols etc., there were some backward-incompatible ABI changes which require you to bump the shared library package name to something like libfoo1a and you should start over again.) $ cd libfoo-1.3     $ debuild ... dpkg-gensymbols: warning: some new symbols appeared in the symbols file: ... see diff output below --- debian/libfoo1.symbols (libfoo1_1.3-1_amd64) +++ dpkg-gensymbolsFE5gzx 2012-11-11 02:24:53.609667389 +0900 @@ -127,6 +127,7 @@ foo_get_name@Base 1.1 foo_get_longname@Base 1.2 foo_get_type@Base 1.1 + foo_get_longtype@Base 1.3-1 foo_get_symbol@Base 1.1 foo_get_rank@Base 1.1 foo_new@Base 1.1 ... * If you see the diff printed by the dpkg-gensymbols as above, extract the updated proper symbols file from the generated binary package of the shared library. ^[99] $ cd .. $ dpkg-deb -R libfoo1_1.3_amd64.deb libfoo1-tmp $ sed -e 's/1\.3-1/1\.3/' libfoo1-tmp/DEBIAN/symbols \ >libfoo-1.3/debian/libfoo1.symbols * Build release packages with tools such as debuild and pdebuild. $ cd libfoo-1.3 $ debuild clean $ debuild ... In addition to the above examples, we need to check the ABI     compatibility further and bump versions for some symbols manually as needed. ^[100] Although it is only a secondary reference, Debian wiki     UsingSymbolsFiles (http://wiki.debian.org/UsingSymbolsFiles) and its linked web pages may be useful. A.3. Multiarch The multiarch feature introduced to Debian wheezy integrates     support for cross-architecture installation of binary packages (particularly i386<->amd64, but also other combinations) in dpkg and apt. You should read the following references in detail. * Ubuntu wiki MultiarchSpec (https://wiki.ubuntu.com/ MultiarchSpec) (upstream)     * Debian wiki Multiarch/Implementation (http://wiki.debian.org/ Multiarch/Implementation) (Debian situation) It uses the triplet such as i386-linux-gnu and x86_64-linux-gnu for the install path of shared libraries. The actual triplet path     is dynamically set into $(DEB_HOST_MULTIARCH) value by dpkg-architecture(1) for each build. For example, the path to install multiarch libraries are changed as follows.^[101] +-------------------------------------------------------------+ |Old path |i386 multiarch path |amd64 multiarch path |     |---------+------------------------+--------------------------| |/lib/ |/lib/i386-linux-gnu/ |/lib/x86_64-linux-gnu/ | |---------+------------------------+--------------------------| |/usr/lib/|/usr/lib/i386-linux-gnu/|/usr/lib/x86_64-linux-gnu/| +-------------------------------------------------------------+     Here are some typical multiarch package split scenario examples for the followings: * a library source libfoo-1.tar.gz     * a tool source bar-1.tar.gz written in a compiled language * a tool source baz-1.tar.gz written in an interpreted language +---------------------------------------------------------------+ |Package |Architecture:|Multi-Arch:|Package content | |------------+-------------+-----------+------------------------| |libfoo1 |any |same |the shared library, | | | | |co-installable | |------------+-------------+-----------+------------------------| |libfoo1-dbg |any |same |the shared library debug| | | | |symbols, co-installable | |------------+-------------+-----------+------------------------| | | | |the shared library | |libfoo-dev |any |same |header files etc., | | | | |co-installable | |------------+-------------+-----------+------------------------| | | | |the run-time support |     |libfoo-tools|any |foreign |programs, not | | | | |co-installable | |------------+-------------+-----------+------------------------| |libfoo-doc |all |foreign |the shared library | | | | |documentation files | |------------+-------------+-----------+------------------------| | | | |the compiled program | |bar |any |foreign |files, not | | | | |co-installable | |------------+-------------+-----------+------------------------| |bar-doc |all |foreign |the documentation files | | | | |for the program | |------------+-------------+-----------+------------------------| |baz |all |foreign |the interpreted program | | | | |files | +---------------------------------------------------------------+ Please note that the development package should contain a symlink     for the associated shared library without a version number. E.g.: /usr/lib/x86_64-linux-gnu/libfoo.so -> libfoo.so.1 A.4. Building a shared library package     You can build a Debian library package enabling the multiarch support using dh(1) as follows. * Update debian/control. o Add Build-Depends: debhelper (>=9) for the source package section. o Add Pre-Depends: ${misc:Pre-Depends} for each shared library binary package. o Add Multi-Arch: stanza for each binary package section. * Set debian/compat to "9". * Adjust the path from the normal /usr/lib/ to the multiarch /usr/ lib/$(DEB_HOST_MULTIARCH)/ for all packaging scripts. o Call DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) in debian/rules to set DEB_HOST_MULTIARCH variable, first.     o Replace /usr/lib/ with /usr/lib/$(DEB_HOST_MULTIARCH)/ in debian/rules. o If ./configure is used in the part of override_dh_auto_configure target in debian/rules, make sure to replace it with dh_auto_configure -- . ^[102] o Replace all occurrences of /usr/lib/ with /usr/lib/*/ in debian/foo.install files. o Generate files like debian/foo.links from debian/foo.links.in dynamically by adding a script to override_dh_auto_configure target in debian/rules. override_dh_auto_configure: dh_auto_configure sed 's/@DEB_HOST_MULTIARCH@/$(DEB_HOST_MULTIARCH)/g' \ debian/foo.links.in > debian/foo.links Please make sure to verify that the shared library package     contains only the expected files, and that your -dev package still works. All files installed simultaneously as the multiarch package to     the same file path should have exactly the same file content. You must be careful on differences generated by the data byte order and by the compression algorithm. --------------     ^[89] Alternatively: readelf -d libfoo.so.1 | grep SONAME     ^[90] Alternatively: readelf -d libfoo.so.1 | grep NEEDED ^[91] See Debian Policy Manual, 8.1 "Run-time shared libraries"     (http://www.debian.org/doc/debian-policy/ch-sharedlibs.html# s-sharedlibs-runtime) .     ^[92] See Debian Policy Manual, 8.1.1 "ldconfig" (http:// www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-ldconfig) . ^[93] See Debian Policy Manual, 8.3 "Static libraries" (http:// www.debian.org/doc/debian-policy/ch-sharedlibs.html#     s-sharedlibs-static) and Debian Policy Manual, 8.4 "Development files" (http://www.debian.org/doc/debian-policy/ ch-sharedlibs.html#s-sharedlibs-dev) .     ^[94] See Debian wiki ReleaseGoals/LAFileRemoval (http:// wiki.debian.org/ReleaseGoals/LAFileRemoval) .     ^[95] See Debian wiki RpathIssue (http://wiki.debian.org/ RpathIssue) . ^[96] Backward-incompatible ABI changes normally require you to     update the SONAME of the library and the shared library package name to new ones. ^[97] For C++ libraries and other cases where tracking individual     symbols is too difficult, follow Debian Policy Manual, 8.6.4 "The shlibs system" (http://www.debian.org/doc/debian-policy/ ch-sharedlibs.html#s-sharedlibs-shlibdeps) , instead. ^[98] All previous versions of Debian packages are available at http://snapshot.debian.org/ (http://snapshot.debian.org/) . The     Debian revision is dropped from the version to make it easier to backport the package: 1.1 << 1.1-1~bpo70+1 << 1.1-1 and 1.2 << 1.2-1~bpo70+1 << 1.2-1     ^[99] The Debian revision is dropped from the version to make it easier to backport the package: 1.3 << 1.3-1~bpo70+1 << 1.3-1 ^[100] See Debian Policy Manual, 8.6.2 "Shared library ABI     changes" (http://www.debian.org/doc/debian-policy/ ch-sharedlibs.html#s-sharedlibs-updates) .     ^[101] Old special purpose library paths such as /lib32/ and / lib64/ are not used any more. ^[102] Alternatively, you can add --libdir=\$${prefix}/lib/$ (DEB_HOST_MULTIARCH) and --libexecdir=\$${prefix}/lib/$ (DEB_HOST_MULTIARCH) arguments to ./configure. Please note that     --libexecdir specifies the default path to install executable programs run by other programs rather than by users. Its Autotools default is /usr/libexec/ but its Debian default is /usr /lib/.