Fedora 新软件维护者指南

前言
本文旨在解说软件包维护的概括流程，使中文地区一些英文能力稍逊的 Fedora 软件包维护人员能够更了解如何管理软件包. 希望更多使用中文的 Fedora 爱好者能够加入，参与建设 Fedora 社区.

本文仍在更新中，如有错误，请不吝指正.

安装软件包维护工具
作为一位新的 Fedora 软件包维护人员，你需要拥有一套 Fedora 的软件包维护工具；本文建议你首先安装 fedora-packager 这个软件包. 由于 fedora-packager 依赖了 Fedora 众多相关的软件包管理工具，因此安装此软件包也随即会安装上 rpmdevtools、mock、koji 和 bodhi 等工具. 这些工具在后面的软件包维护中起到重要作用. 而 rpmfusion-packager 则对应地添加了 RPM Fusion 打包的相关工具.

安装 fedora-packager 软件包，请在终端界面输入以下指令：

su -c 'yum install fedora-packager'

安装 rpmfusion-packager 前，请先确认已经开启 RPM Fusion 的软件源：

su -c 'yum install rpmfusion-packager'

申请 FAS 和 Bugzilla 帐户
要正式成为 Fedora 的软件包维护人员，你需要申請一个 FAS 帐号和 Red Hat Bugzilla 的帐号. 申请这两个用户的方法都非常简单，详細步骤可查阅其他有关文档，本文只就此简述. 成为 RPM Fusion Packager 则需要 RPM Fusion 的 FAS 帐号和 Bugzilla 帐号. 两者并不通用，但建议是使用同一邮件地址和用户 ID.


 * 申请 FAS 帐户，地址如下： https://admin.fedoraproject.org/accounts/ . 而 RPM Fusion 的地址则是 https://fas.rpmfusion.org/accounts/.
 * 注冊完成后，还需要登录 FAS 签署 CLA、上传公共 SSH 密钥、PGP 密钥，并申请加入 Fedora Packager CVS Commit Group. RPM Fusion 则是申请 RPM Fusion Packagers CVS commits Group. 两者应使用同一个 SSH 密钥和 PGP 密钥.


 * 申请 Bugzilla 帐户，地址如下： https://bugzilla.redhat.com/ . RPM Fusion Bugzilla 则是 https://bugzilla.rpmfusion.org/.
 * 注意，在 FAS 注册所使用的电子邮件地址必须要与 Bugzilla 的电子邮件地址一致.

查询你要打包的软件是否已经存在于 Fedora Package Database
为新软件打包之前，需要在 Fedora Package Database https://admin.fedoraproject.org/pkgdb 查询该软件包是否已经存在. 如果存在，则无需要为该软件制作 RPM 包，因为软件仓库已经有该软件. 另外，进入 Fedora 官方源的软件包必须是使用符合 OSL 的开源许可证，被 Fedora 任何的许可证可在以下链接查阅： http://fedoraproject.org/wiki/Licensing#SoftwareLicenses

RPM Fusion 并没有使用 pkgdb. 如果你想查看你打算打包的软件是否在 RPM Fusion，可以查看他们的 CVS 树. RPM Fusion Free 软件库在 http://cvs.rpmfusion.org/viewvc/rpms/?root=free. RPM Fusion Nonfree 软件库在 http://cvs.rpmfusion.org/viewvc/rpms/?root=nonfree.


 * 注释：Fedora 是红帽公司资助的一个社区项目. Fedora 只允许开源而且不抵触美国法律的软件进入其官方仓库. RPM Fusion Free 是容纳使用开源许可证，但不符合 Fedora Package Guideline 要求的软件. 比如 FFmpeg 和 x264，需要使用 GPL 许可证，但是因为 H.264 的专利争议而无法加入 Fedora 官方仓库. RPM Fusion Nonfree 是容纳免费，但是非开源，非商业，而且可再公开分发的软件，比如 NVIDIA 和 AMD 的官方闭源驱动.

在本地计算机构建一个 rpm 包
要成为软件包维护人员，首先要学会如何构建一个软件包. 在此简略地介绍一下在本地计算机上构建一个软件包的步骤.

首先在本地 rpmbuild 的编译树. 从 Fedora Core 5 开始，Fedora 不建议打包者使用 root 来构建 RPM 包，所以一般在普通用户的 home 目录上建立编译树. 建立编译树的命令如下：

rpmdev-setuptree

此时，rpmdevtools 会在 $HOME 目录下建立一个 rpmbuild 的目录，并且里面会有六个目录：SOURCES, SRPMS, RPMS, BUILD, BUILDROOT, SPECS. 然后以 foo（假设软件包名称为 foo） 在SPECS目录里新建一个 spec 文件.

rpmdev-newspec foo

编辑好 spec 文件后，把源代码包和补丁都放到 SOURCES 目录，那就可以正式构建 rpm 包了：

rpmbuild -ba foo.spec

维护者可以根据 rpmbuild 的各项参数进行调节，"-ba" 参数会构建出 src.rpm 包和 rpm包. 然后是用 rpmlint 检测 rpm 包是否出现错误. rpmlint 可以检查 spec 文件、rpm 包和 src.rpm 包.

rpmlint pkgname.spec rpmlint pkgname.src.rpm rpmlint pkgname.i586.rpm // 若该软件包是i586架构的.

关于本地打包，可参考 RPM 打包教学 https://fedoraproject.org/wiki/Zh/Docs/RPM%E6%89%93%E5%8C%85%E6%95%99%E5%AD%B8

Mock
Mock 是一個用本地系統模拟编译环境，测试 RPM 建立正确性的工具. 使用 Mock 的好处是显然易见的：Mock 建立一个沙盘模式以确保 BuildRequire 内容的正确性.

安装好 Mock 以后，即可馬上使用：

mock -r rebuild pkgname.src.rpm

（ 是位于 /etc/mock 里面，配置文档的名称；只需要輸入文件名，扩展名必须省略. ）

因为要从源服务器上下载大量的 rpm 包以模拟编译环境；所以 Mock 的执行会耗费比较多时间. 如果网络连接速度不是很快的朋友，建议不要使用这种办法，或者可以参考通过建立本地源的办法加快下载速度 http://fedoraproject.org/wiki/Docs/Drafts/MockSetupUsingLocalMirror. 若是在 Mock 通过测试，则大抵可以说这个软件包足够稳定了.

Koji
跟 Mock 相反， Koji 是帮助软件包维护人员用 Fedora 网上集成编译环境進行测试的工具. 因为编译环境就是官方发行版使用的系統，所以测试结果将会非常可靠. 而 RPM Fusion 则是坚持使用 Plague. 实质上，两者都是架设在远程服务器的 Mock.

使用 Koji 的前提是，需要安装相关的管理员证书. Fedora 官方证书是从 https://admin.fedoraproject.org/accounts/user/gencert 下载并保存到 ~/.fedora.cert. 而 RPM Fusion 的证书则从 从 https://fas.rpmfusion.org/accounts/user/gencert 下载并保存到 ~/.rpmfusion.cert

保存好后，运行如下命令：

fedora-packager-setup

RPM Fusion 的是如下命令：

rpmfusion-packager-setup

随后生成一份 fedora-browser-cert.p12 证书，你可以把这份证书添加到浏览器中，那么就可以通过浏览器登录 koji 的 web 界面. 因为 RPM Fusion 仍然使用 Plague，因此运行 rpmfusion-packager-setup 是不会有 p12 证书生成的. RPM Fusion 计划未来会跟随 Fedora 转用 Koji，但没有公布具体时间表.

使用 koji 来测试软件包的命令如下，RPM Fusion 资源所限，禁止使用 Scratch Build：

koji build --scratch targets pkgname.src.rpm

查看 targets 可以通过以下命令：

koji list-targets

关于 Mock 的其他使用，可以参考 Mock 教学 https://fedoraproject.org/wiki/Zh/Mock_%E6%95%99%E5%AD%A6

在 Bugzilla 上发布软件包审核请求 (Package Review)
软件包进入 Fedora 官方源前，需要通过严格的审核. 软件包要先通过完整的审核流程，确保质量上完全没有问题後，才可以进入 Fedora 的官方源. 同样进入 RPM Fusion 的软件也需要进入类似的流程

作为一名没有被 sponsored（担保）的打包者，你的软件包审核申请必须被 Sponsor（担保人）查阅，审核并通过. 当这个软件包通过审核流程以后，Sponsor 往往要求你再提交一到两个软件包的审核申请；当这些软件包都有审核通过的时候，Sponsor 就会认可你的打包能力而為你担保，正式批准你成为 Fedora 的软件包维护者 (Package Maintainer). 只有你成为正式的软件包维护者，你才有权限去维护和更新你申请的软件包. 如果你已经是Fedora的维护者，你的新软件包申请只需要高级维护者通过 (Proven Packager) 即可.

软件包审核请求的例子可参阅：

https://bugzilla.redhat.com/show_bug.cgi?id=493246

Bugzilla 提交新 bug 報告的页面上： ＊ 然后，就在最后点击Commit的按钮.
 * 在 Component 项选择 Package Review
 * 在 URL 项上则填上软件包的项目主页地址
 * 在 CC 上填入申请者的有效邮件地址
 * 在 Summary 上，则填入 Review Rquest: foo （假设软件包的名称是 foo）
 * 关键点在 Description 上：你需要提供一个 spec 文件和一个 src.rpm 文件的下载地址，方便审核者查看和审阅. 另外，申请者还需也要提供一份关于软件包的较为详细的介绍.

审核需要等待数日才会有 Sponsor 去参与审核你的申请. 而审核的标准，则是这一份 Package Guideline https://fedoraproject.org/wiki/Packaging:Guidelines (请求翻译者翻译). 如果你的申请出现问题，审批者会要求你重新提供修正后的 spec 文件和 src.rpm 文件.这里可能要花费一段时间. 当 Sponsor 批准你的申请以后，你申请 Git 空间来存放软件包的代码和 spec 文件. 回到 Bugzilla 的页面，把 fedora-cvs 的 flags 改为 "?" 并且在新的 comment 输入 CVS 申请的信息. 內容如下：

New Package SCM Request

=
========== Package Name: pkgname Short Description: summary of package Owners: foo bar Branches: f14 f15 f16 el6 InitialCC: baz


 * "Package Name": 软件包名称
 * "Short Description": 软件包的简短描述
 * "Owners": 候任软件包维护者之 FAS 帐号
 * "Branches": devel(rawhide) 以外请求的版本 CVS 分支，以作往后移植 (backport) 之用.
 * "InitialCC": 软件包版本更新時，会向其会送副本的 FAS 帐号；一般为 FAS 所使用的邮件列表，请查阅有关文档.

RPM Fusion Bugzilla 没有 Flags 表示 Package Review 的进度. 当软件包 Review 通过以后，Reviewer 会添加 Block 到 #4，Bug Report 会依赖 https://bugzilla.rpmfusion.org/show_bug.cgi?id=4. 此时 Packager 应该添加 Block 到 #33，让 Bug Report 依赖 https://bugzilla.rpmfusion.org/show_bug.cgi?id=33 ，作为申请 CVS 空间存放相关文件.

Package CVS request

=
========= Package Name: Short Description: Owners: Branches: InitialCC: -- License tag: [free|nonfree]

RPM Fusion 的 SCM 申请最后增加了 License Tag，表示该软件是进入 Free 还是 Nonfree 软件仓库.

汇入软件包代码到 Git 服务器 (Fedora)
自 Fedora 14 开始，Fedora当 Git 管理员把 fedora-cvs 的 flags 改为”+”的时候，表示线上的 Git 已完成建立，第一次使用 Git 建议在 ~/rpmbuild 里建立 GIT 目录方便管理：

mkdir -p ~/rpmbuild/GIT

进入 GIT 目录，你就可以在本地计算机上检出 (checkout) Git 分支：

fedpkg clone pkgname

完成后，请把获批准的 src.rpm 包汇入 Git 服务器. 先进入 Git 目录，假设你的软件包是放在 $HOME 里，执行以下命令：

fedpkg upload ~/pkgname.src.rpm

维护者可以根据每个 Fedora 版本分支 (branch) 逐个上传，默认是在 master 分支是指向 Rawhide，Fedora 16 的分支是 f16. 上传完成后，就可以在 koji 上编译打包你维护的软件包.

提交更改：

git commit

填写 Changelog 以后把修改的内容上传到 Git 服务器：

git push

把 Git 上传的内容同步到本地计算机：

git pull

然后开始编译打包：

fedpkg build

每一个更新理应每一个分支，如果每一个分支更新的内容不一样，请在每一个更新上重复以上步骤. 如果是一样，在完成以上步骤以后，

首先切换分支：

fedpkg switch-branch f16

或

git checkout f16

合并分支到 master (假定 f16 分支和 master 分支的内容是一致的)：

git merge master

把更改的内容提交到 Git 服务器：

git push

把 Git 上传的内容同步到本地计算机：

git pull

然后开始编译打包：

fedpkg build

注意：编译打包并不是在本地计算机上进行，而是在远程服务器进行的，所以在编译打包过程中并不会占用你的系统资源. 但是由于网络延迟的关系，有时候需要很长时间才能从远程服务器反馈信息到本地计算机；然而终端信息显示与否，绝不影响远程服务器编译进度.

推送软件包更新到 Bodhi (Fedora)
当编译完成后，终端会反馈出编译是否出错，同时你的邮箱就会得到一份邮件较为详细的报告. 倘若非 devel 分支的编译打包成功，则需要把软件包推送到 bodhi. bodhi 有命令行和网页界面两种方式，一般推荐使用网页界面的操作. 登入 Bodhi https://admin.fedoraproject.org/updates/ 之后，点击 New Updates，新建一个更新请求. 然后在Package 项输入要申请的软件包名称，版本号，隶属的分支，格式一般为：

shutter-0.80.1-2.fc11


 * Type 为 newpackage
 * Request 为 testing
 * Bugs 为审核申请在 Bugzilla 的 ID
 * Notes 为简要地介绍软件包内容

随后则可以点击 Save Update. 这里需要审核的过程，大约几天的时间. 审核过程中管理员还会在 Koji 重新编译软件包，并在打包的时候添加 GPG 密钥. 当审核通过的时候，软件包就会出现 updates-testing 的软件库里. 此时你需要把 Request 改成 stable，如果维护者早前在 Bugs 里输入了 ID，Bugzilla 则会自动关闭审核申请. 当软件包通过最后的审核，则会出现在 updates 上，整个新软件包审核流程就会结束.

重申，另外 devel 分支的软件包无需推送到 bodhi，会直接被推送到 rawhide 的软件库.

更新已有的软件包 (Fedora)
当软件包更新到新的版本以后，维护者有义务更新软件库内的版本. 一般的维护者只能维护自己申请的软件包和获得维护权的软件包. 作为维护者，你可以使用像新软件包的办法把 src.rpm 文件汇入到去 CVS 服务器后编译来更新软件包，而以下则是介绍另外一种办法.

首先把新软件包的源代码压缩包放置在软件包的 Git 目录里，默认是 master 分支. 然后上传到 Git 服务器，建议在上传成功后就马上删除此文件：

fedpkg upload pkgname.tar.gz

然后把修改过的 spec 文件，其余与编译有关的文件添加到提交序列，例如程序补丁，图标，徽标等：

git add pkgname.spec git add packagename-fix-the-foobar.patch git add sources

提交更改的内容并填写 Changelog：

git commit

如果增加和修改的文件比较多，可以直接用以上命令提交，无须逐一文件添加到序列：

git commit -a

把更改的内容推送到 Git 服务器：

git push

更新本地分支的文件：

git pull

设置编译器构建软件包：

fedpkg build

最后还是需要像新软件包那样把更新推送到 bodhi. 使用以下命令可以方便地把更新推送到bodhi：

fedpkg update

如同上文所述，软件包维护者应当切换到不同的分支为不同的 Fedora 版本提供更新. 一般而言，每一次更新都是用相同的源代码包给不同的 Fedora 版本，因此源代码包上传一次即可. sources 文件是记录和校验源代码包，应当在提交更改的时候附上.

当 Fedora 发布新版本的时候，维护者应当进入 Git 目录同步新的分支到本地：

git fetch

在没有完成提交过程的时候，Git 是不允许使用者切换分支的. 此时可以先暂存更改的代码，在完成其他分支的工作后继续修改. 暂存时：

git stash

回来时：

git stash apply

汇入软件包代码到 CVS 服务器 (RPM Fusion)
当 CVS 管理员批准了 Packager 的 CVS 请求的时候，这表示线上的 CVS 已完成建立，你就可以在本地计算机上检出 (checkout) CVS 分支. 第一次使用 RPM Fusion CVS 需要配置相应的环境变量：

mkdir -p ~/rpmbuild/CVS export CVSROOT=:ext:username@cvs.rpmfusion.org:~/rpmbuild/CVS/ export CVS_RSH=ssh


 * username 是 Packager 在 RPM Fusion FAS 上的 ID.

如果你不想每次开机都重新设置，可以把以下两项命令加入到 ~/bashrc：

export CVSROOT=:ext:username@cvs.rpmfusion.org:~/rpmbuild/CVS/ export CVS_RSH=ssh

从 RPM Fusion Free 检出 CVS 分支的是：

rpmfusion-free-cvs pkgname

RPM Nonfree 的是：

rpmfusion-nonfree-cvs pkgname

完成后，请把获批准的 src.rpm 包汇入 CVS 服务器. 先进入CVS目录，假设你的软件包是放在 $HOME 里，执行以下命令：

./common/cvs-import.sh -b F-11 -m "import Joe's update" ~/pkgname.src.rpm

维护者需要根据每个 Fedora 版本分支 (branch) 逐个上传，F-11 对应的是 Fedora 11 的分支，而 devel 则对应的是 Rawhide 的分支，以此类推. 上传完成后，就可以在 koji 上编译打包你维护的软件包.

首先把CVS上传的内容同步到本地计算机：

cvs up

然后开始编译打包：

make build

和把软件包汇入到 CVS 服务器一样，你也需要逐个进入每个发行版的分支来编译打包. 注意：编译打包并不是在本地计算机上进行，而是在远程服务器进行的，所以在编译打包过程中并不会占用你的系统资源. 但是由于网络延迟的关系，有时候需要很长时间才能从远程服务器反馈信息到本地计算机；然而终端信息显示与否，绝不影响远程服务器编译进度. RPM Fusion 的资源较少，编译打包时间需要更多的时间. RPM Fusion 没有使用 bodhi，当软件包在 Plague 编译完成后，devel 分支就会自动进入 Rawhide 软件仓库，F-15 和 F-14 分支就会进入 updates-testing 软件仓库. 如果没有重大 Bug Report 报告，一个星期后进入 updates 软件仓库. RPM Fusion Wiki 的另一个说法似乎是 Packager 需要自行手动推送.

更新已有的软件包 (RPM Fusion)
当软件包更新到新的版本以后，维护者有义务更新软件库内的版本. 一般的维护者只能维护自己申请的软件包和获得维护权的软件包. 作为维护者，你可以使用像新软件包的办法把 src.rpm 文件汇入到去 CVS 服务器后编译来更新软件包，而以下则是介绍另外一种办法.

更新前，Packager 需要配置相应的环境变量：

export CVSROOT=:ext:username@cvs.rpmfusion.org:~/rpmbuild/CVS/ export CVS_RSH=ssh


 * username 是 Packager 在 RPM Fusion FAS 上的 ID.

如果你不想每次开机都重新设置，可以把以下两项命令加入到 ~/bashrc：

export CVSROOT=:ext:username@cvs.rpmfusion.org:~/rpmbuild/CVS/ export CVS_RSH=ssh

把新软件包的源代码压缩包放置在 Fedora 分支的目录里，然后上传到 CVS 服务器：

make upload FILES=”pkgname.tar.gz”

然后把其余与编译有关的文件上传到 CVS 服务器，例如程序补丁，图标，徽标等：

cvs add packagename-fix-the-foobar.patch

确保所有被更改的部分完整正确：

cvs diff -u

提交维护者对软件包更改的内容：

cvs commit

标记软件包版本，注意：标记的版本号是根据 spec 文件里维护者所表示填写的版本号，这个版本号必须要比之前的要更高，否则在编译的时候会出现版本号问题：

make tag

设置编译器构建软件包：

make build

同样，因为 RPM Fusion 没有使用 bodhi，当软件包在 Plague 编译完成后，devel 分支就会自动进入 Rawhide 软件仓库，F-15 和 F-14 分支就会进入 updates-testing 软件仓库. 如果没有重大 Bug Report 报告，一个星期后进入 updates 软件仓库. RPM Fusion Wiki 的另一个说法似乎是 Packager 需要自行手动推送.


 * 本页面最后更新于 2011 年 9 月 13 日.