查看“Debian-maint-guide/9”的源代码

= Debian新维护人员手册  =

== 第 9 章 - 更新软件包  ==

=== 9.1 新的Debian修订版  ===

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

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

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

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

*在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

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

*更换到目录“../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软件包升级为新版本。 
#*解压源码包，并修改源码树的根目录为&lt;packagename&gt;-&lt;upstream_version&gt;/并“cd”到此目录中。 
#*复制父目录中的源码包并将其更名为&lt;packagename&gt;_&lt;upstream_version&gt;.orig.tar.gz。 
#*对新的源码树也进行与旧源码树一样的修改。可能的方法有： 
#*#“zcat /path/to/&lt;packagename&gt;_&lt;old-version&gt;.diff.gz | patch -p1”命令， 
#*#“uupdate”命令 
#*#“svn merge”命令，如果你使用Subversion仓库来管理源码，或者 
#*#直接将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专用的源码包，你必须手工复制上游软件包到父目录中，并将其名称改为&lt;packagename&gt;_&lt;upstream_version&gt;.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最新的发布中的那个版本上，所以要记得测试从那个版本升级的情况。