前言
本文旨在解说软件包维护的概括流程，使中文地区一些英文能力稍逊的 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 和 Koji 去测试 RPM 包
Mock
Mock 是一個用本地系統模拟编译环境，测试 RPM 建立正确性的工具。使用 Mock 的好处是显然易见的：Mock 建立一个沙盘模式以确保 BuildRequire 内容的正确性。
安装好 Mock 以后，即可馬上使用：
mock -r <configfile> rebuild pkgname.src.rpm
（<configfile> 是位于 /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 報告的页面上：
- 在 Component 项选择 Package Review
- 在 URL 项上则填上软件包的项目主页地址
- 在 CC 上填入申请者的有效邮件地址
- 在 Summary 上，则填入 Review Rquest: foo （假设软件包的名称是 foo）
- 关键点在 Description 上：你需要提供一个 spec 文件和一个 src.rpm 文件的下载地址，方便审核者查看和审阅。另外，申请者还需也要提供一份关于软件包的较为详细的介绍。
＊ 然后，就在最后点击Commit的按钮。
审核需要等待数日才会有 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 日。