Debian新维护人员手册

第 9 章 - 更新软件包

9.1 新的Debian修订版

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

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

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

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

在changelog的项目上包含一份对bug的简短描述以及解决方法，并将它附加在“Closes: #54321”之后。这样，当你的软件包被Debian文档库接受的时候，这个bug报告将会被文档维护软件自动关闭。

重复你在完整的rebuild, 第 6.1 节、检查软件包中的错误, 第 7 章和上传软件包, 第 8 章中所做的。不同的是这一次，原始的源代码将不会被包括，因为它们并没有被修改并且已经存在于Debian的文档库中了。

9.2 新的上游版本(基本)

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

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

            uupdate -u gentoo-0.9.13.tar.gz

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

更换到目录“../gentoo-0.9.13”中，它是新的软件包源码目录树，重复你在完整的rebuild, 第 6.1 节、检查软件包中的错误, 第 7 章和上传软件包, 第 8 章中所做的。

注意如果你已经如watch.ex, 第 5.10 节所述建立了一个“debian/watch”文件，那么你就可以通过运行uscan(1)来自动检测新版本的源代码并下载它们，然后运行uupdate。

9.3 新的上游版本 (实际的)

当为Debain档案库准备软件包时，你必须仔细检查最终的软件包。下面是一个更加实际的过程。

校验上游修改
- 阅读上游的changelog、NEWS及其它可能和新版本一起发布的文档。
- 用“diff -urN”比较新旧上游软件包的差别，从而对修改的范围有个概略性的了解，哪些工作已经完成了(同时因此在哪里可能会有新的bug)，而且还要留心观察任何值得怀疑的东西。
把旧Debian软件包升级为新版本。
- 解压源码包，并修改源码树的根目录为<packagename>-<upstream_version>/并“cd”到此目录中。
- 复制父目录中的源码包并将其更名为<packagename>_<upstream_version>.orig.tar.gz。
- 对新的源码树也进行与旧源码树一样的修改。可能的方法有：
  1. “zcat /path/to/<packagename>_<old-version>.diff.gz | patch -p1”命令，
  2. “uupdate”命令
  3. “svn merge”命令，如果你使用Subversion仓库来管理源码，或者
  4. 直接将debian/目录从旧源码树复制到新的源码树中，如果它是用dpatch打包的。
- 保留旧的修改日志项目(看上去不重要，但其实随时会有意外...)
- 新软件包的版本应该由上游版本号加上Debian修订号-1构成，例如“0.9.13-1”。
- 在debian/changele文件的顶部为此新版本添加修改日志项目 ——“新的上游版本”。例如“dch -v 0.9.13-1”.
- 简要地说明新上游版本中修复的已报bug并在修改日志中关闭这些bug。
- 简要地说明维护者为修复已报bug对新上游版本所做的修改并且在修改日志中关闭这些bug。
- 如果补丁或者合并的过程并不顺利，就要仔细地查出哪些地方有错误(在.rej文件中会留下线索。)多数情况下是因为你使用的补丁已经整合到上游版本中，这样就不再需要那补丁了。
- 向新版本的升级应当是安静地且不会打扰到用户(除非是发现旧的bug已经被修复或者增加了新的功能，已有的用户应当不会注意到升级。) [4]
- 如果你处于某种原因需要已经删除的模板文件，你可以在同一个已经“debian化” 的目录中再次运行dh_make，运行时加上-o选项。然后就可以修改它了。
- 应当对已经存在的Debian修改进行重新评估；除非有什么不得已的原因，都应当删除掉上游作者已经合并的(无论何种形式)并继续保留上游作者并未合并的。
- If any changes were made to the build system (hopefully you'd know from the step 1 and update the debian/rules and debian/control build dependencies if necessary.
如debuild命令, 第 6.3 节或pbuilder包, 第 7.6 节所述构建新的软件包。最好是使用pbuilder。
核对新软件包是否构造正确。
- 执行检查软件包中的错误, 第 7 章.
- 执行校验软件包的升级, 第 9.6 节.
- 在此检查是否有已经修复但在Debian Bug跟踪系统(BTS)仍然为开启状态的bug。
- 检查.changes文件的内容以确认你把软件包上传到了正确的发行版中、已经关闭的bug已经列出在“Closes:”域中，而“Maintainer:Check”和“Changed-By:”域可以匹配，以及文件已经用GPG签署等等。
如果为修正任何内容而修改了软件包，请返回到第2步直到满意。
如果你需要别人帮助才可以上传，请一定要注意在构造软件包的时候使用特殊的选项(如“dpkg-buildpackage -sa -v ...”)，同时请通知帮助你上传的人以便他/她能够正确构造软件包。
如果你自己上传，执行上传软件包, 第 8 章.

9.4 orig.tar.gz文件

如果你构造软件时使用的源码树只有debian/目录而没有orig.tar.gz文件在其父目录中，最后你将得到一个Debian专用源码包，而没有diff.gz文件。这种包装方式应当仅对那些Debian专用的软件适用，这些软件包在其它发行版中应当是完全没有用处的。 [5]

要获得由orig.tar.gz和diff.gz两个文件构成的非Debian专用的源码包，你必须手工复制上游软件包到父目录中，并将其名称改为<packagename>_<upstream_version>.orig.tar.gz，如首次“Debian化”, 第 2.4 节所述由dh_make所做的那样。

9.5 cvs-buildpackage命令和similes

你应当考虑使用一些源码关系系统来管理软件包。有几个脚本已经被定制用于和多数流行的系统一起工作。

CVS
- cvs-buildpackage
Subversion
- svn-buildpackage
Arch (tla)
- tla-buildpackage
- arch-buildpackage

这些命令也可以使对新版上游软件的打包自动化。

9.6 校验软件包的升级

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

从原先的版本升级，

降级到原先的版本并删除它，

安装新的软件包，

删除它然后重新安装它一遍，

彻底清楚它。

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

Debian-maint-guide/9

目录