Fedora 新软件维护者指南

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(安装软件包维护工具)
Line 13: Line 13:
  
  
作为一位新的 Fedora 软件包维护人员,你需要拥有一套 Fedora 的软件包维护工具;本文建议你首先安装 fedora-packager 这个软件包。由于 fedora-packager 依赖了 Fedora 众多相关的软件包管理工具,因此安装此软件包也随即会安装上 rpmdevtools、mock、koji 和 bodhi 等工具。这些工具在后面的软件包维护中起到重要作用。
+
作为一位新的 Fedora 软件包维护人员,你需要拥有一套 Fedora 的软件包维护工具;本文建议你首先安装 fedora-packager 这个软件包。由于 fedora-packager 依赖了 Fedora 众多相关的软件包管理工具,因此安装此软件包也随即会安装上 rpmdevtools、mock、koji 和 bodhi 等工具。这些工具在后面的软件包维护中起到重要作用。而 rpmfusion-packager 则对应地添加了 RPM Fusion 打包的相关工具。
  
安装 fedora-packager 软件包,请在终端界面輸入以下指令:
+
安装 fedora-packager 软件包,请在终端界面输入以下指令:
  
 
<pre>su -c 'yum install fedora-packager'</pre>
 
<pre>su -c 'yum install fedora-packager'</pre>
  
 +
安装 rpmfusion-packager 前,请先确认已经开启 RPM Fusion 的软件源:
 +
 +
<pre>su -c 'yum install rpmfusion-packager'</pre>
  
 
=== 申请 FAS 和 Bugzilla 帐户 ===
 
=== 申请 FAS 和 Bugzilla 帐户 ===

Revision as of 20:43, 12 September 2011

Contents

前言

本文旨在解说软件包维护的概括流程,使中文地区一些英文能力稍遜的 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 的帐号。申请这两个用户的方法都非常简单,详細步骤可查阅其他有关文档,本文只就此简述。

  • 申请 FAS 帐户,地址如下: https://admin.fedoraproject.org/accounts/
  • 注冊完成后,还需要登录 FAS 签署 CLA、上传公共 SSH 密钥、PGP密钥,并申请加入 Fedora Packager CVS Commit Group。
  • 申请Bugzilla帐户,地址如下: https://bugzilla.redhat.com/
  • 注意,在 FAS 注册所使用的电子邮件地址必须要与 Bugzilla 的电子邮件地址一致。


查询你要打包的软件是否已经存在于Fedora Package Database

为新软件打包之前,需要在 Fedora Package Database https://admin.fedoraproject.org/pkgdb 查询该软件包是否已经存在。如果存在,则无需要为该软件制作RPM包,因为软件仓库已经有该软件。另外,进入Fedora官方源的软件包必须是使用符合 OSL 的开源许可证,如果是非开源但是免费且可自由分发的软件,則建议向 RPM Fusion 申请。被 Fedora 任何的许可证可在以下链接查阅: http://fedoraproject.org/wiki/Licensing#SoftwareLicenses


在本地计算机构建一个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 网上集成编译环境進行测试的工具。因為编译环境就是官方发行版使用的系統,所以测试结果将会非常可靠。

使用 Koji 的前提是,需要安装相关的管理员证书。需要安装的是以下 3 份证书。

第一份,从 https://admin.fedoraproject.org/accounts/user/gencert 下载并保存到 ~/.fedora.cert

第二份,从 https://admin.fedoraproject.org/accounts/fedora-upload-ca.cert 下载并保存到 ~/.fedora-upload-ca.cert

第三份,从 https://admin.fedoraproject.org/accounts/fedora-server-ca.cert 下载并保存为 ~/.fedora-server-ca.cert

保存好后,运行如下命令:

fedora-packager-setup

随后生成一份 fedora-browser-cert.p12 证书,你可以把这份证书添加到浏览器中,那么就可以通过浏览器登录koji的web界面。

使用koji来测试软件包的命令如下:

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的官方源。

作为一名没有被 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 批准你的申请以后,你申请 CVS空间来存放软件包的代码和 spec 文件。回到 Bugzilla 的页面,把 fedora-cvs 的 flags 改为 "?" 并且在新的 comment 输入CVS申请的信息。內容如下:

New Package CVS Request
=======================
Package Name: pkgname
Short Description: summary of package
Owners: foo bar
Branches: F-10 F-11 EL-5
InitialCC: baz
  • "Package Name": 软件包名称
  • "Short Description": 软件包的简短描述
  • "Owners": 候任软件包维护者之 FAS 帳號
  • "Branches": devel(rawhide) 以外請求的版本 CVS 分支,以作往后移植 (backport) 之用。
  • "InitialCC": 软件包版本更新時,会向其会送副本的 FAS 帐号;一般为 FAS 所使用的郵件列表,请查阅有关文档。


汇入软件包代码到 Git 服务器 (Fedora)

自 Fedora 14 开始,Fedora当 Git 管理员把 fedora-cvs 的 flags 改为”+”的时候,表示线上的 Git 已完成建立,你就可以在本地计算机上检出 (checkout) CVS 分支。

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

当编译完成后,终端会反馈出编译是否出错,同时你的邮箱就会得到一份邮件较为详细的报告。倘若非 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 管理员吧 rpmfusion-cvs 的 flags 改为”+”的时候,表示線上的 CVS 已完成建立,你就可以在本地计算机上检出 (checkout) CVS 分支。

fedora-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 服务器一样,你也需要逐个进入每个发行版的分支来编译打包。注意:编译打包并不是在本地计算机上进行,而是在远程服务器进行的,所以在编译打包过程中并不会占用你的系统资源。但是由于网络延迟的关系,有时候需要很长时间才能从远程服务器反馈信息到本地计算机;然而终端信息显示与否,绝不影响远程服务器编译进度。

推送软件包更新到bodhi

当编译完成后,终端会反馈出编译是否出错,同时你的邮箱就会得到一份邮件较为详细的报告。倘若非 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 的软件库。

更新已有的软件包

(此段文字存在较多未确定内容)

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

首先把新软件包的源代码压缩包放置在 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

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

make update