From Fedora Project Wiki

No edit summary
m (moved Fedora新套件维护者指南 to Fedora 新软件维护者指南: 标题用词更符合简体中文的文法)
 
(33 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== 前言 ==
== 前言 ==


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


本文旨在提供一个简易的办法,使中文地区的Fedora包管理员能够更方便地去管理软件包,并且希望能够更多的Fedora爱好者成为Fedora的一份子,参与Fedora的社区建设。
本文仍在更新中,如有错误,请不吝指正。


== 准备工作 ==
== 准备工作 ==




安装软件包维护工具
=== 安装软件包维护工具 ===
作为一位新的Fedora软件包维护人员,你需要拥有一套Fedora的软件包维护工具。本文建议你首先安装fedora-packager这个软件包。fedora-packager依赖了Fedora众多的软件包管理工具,安装此软件包也随即会安装上rpmdevtools、mock、koji和bodhi等工具。这些工具在后面的软件包维护中起到重要作用。


su -c 'yum install fedora-packager'


申请FAS和Bugzilla帐户
作为一位新的 Fedora 软件包维护人员,你需要拥有一套 Fedora 的软件包维护工具;本文建议你首先安装 fedora-packager 这个软件包。由于 fedora-packager 依赖了 Fedora 众多相关的软件包管理工具,因此安装此软件包也随即会安装上 rpmdevtools、mock、koji 和 bodhi 等工具。这些工具在后面的软件包维护中起到重要作用。而 rpmfusion-packager 则对应地添加了 RPM Fusion 打包的相关工具。
要成为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-packager 软件包,请在终端界面输入以下指令:
为新软件打包之前,需要在Fedora Package Database查询该软件包是否已经存在。如果存在,则无需要为该软件制作RPM包,因为软件仓库已经有该软件。另外,进入Fedora官方源的软件包必须是使用符合OSL的开源许可证,如果是非开源但是免费且可自由分发的软件,建议向RPM Fusion申请。被Fedora任何的许可证可在一下链接查阅:http://fedoraproject.org/wiki/Licensing#SoftwareLicenses


<pre>su -c 'yum install fedora-packager'</pre>


== 在本地计算机构建一个rpm包 ==
安装 rpmfusion-packager 前,请先确认已经开启 RPM Fusion 的软件源:


<pre>su -c 'yum install rpmfusion-packager'</pre>


作为一名软件包的维护人员,首先要学会如何构建一个软件包。在此,简略地介绍一下在本地计算机上构建一个软件包。
=== 申请 FAS 和 Bugzilla 帐户 ===


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


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


此时,rpmdevtools就会在$HOME目录下建立一个rpmbuild的目录,并且里面会有六个目录:SOURCES, SRPMS,RPMS, BUILD, BUILDROOT,SPECS。然后以软件名为foo在SPECS目录里新建一个spec文件。
* 申请 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 密钥。


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


编辑好spec文件后,把源代码包和补丁都放到SOURCES目录,那就可以正式构建rpm包了。
=== 查询你要打包的软件是否已经存在于 Fedora Package Database ===


rpmbuild -ba foo.spec


维护者可以根据rpmbuild的更项参数进行调节,ba参数则会构建出src.rpm包和rpm包。然后是用rpmlint检测rpm包是否出现错误。rpmlint可以检查spec文件,rpm包和src.rpm包。
为新软件打包之前,需要在 Fedora Package Database https://admin.fedoraproject.org/pkgdb 查询该软件包是否已经存在。如果存在,则无需要为该软件制作 RPM 包,因为软件仓库已经有该软件。另外,进入 Fedora 官方源的软件包必须是使用符合 OSL 的开源许可证,被 Fedora 任何的许可证可在以下链接查阅: http://fedoraproject.org/wiki/Licensing#SoftwareLicenses


rpmlint foo.spec
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 。
rpmlint foo.src.rpm
rpmlint foo.i586.rpm  //若该软件包是i586架构的。


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


== 使用Mock和Koji去测试rpm包 ==
== 在本地计算机构建一个 rpm 包 ==


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


使用Mock的好处是显然意见的,因为Mock是建立了一个沙盘模式以确保BuildRequire内容的正确性。
首先在本地 rpmbuild 的编译树。从 Fedora Core 5 开始,Fedora 不建议打包者使用 root 来构建 RPM 包,所以一般在普通用户的 home 目录上建立编译树。建立编译树的命令如下:
安装好Mock以后,即可使用


mock -r <configfile> rebuild foo.src.rpm
<pre>rpmdev-setuptree</pre>


<configfile>位于/etc/mock里面,配置文档的名称。
此时,rpmdevtools 会在 $HOME 目录下建立一个 rpmbuild 的目录,并且里面会有六个目录:SOURCES, SRPMS, RPMS, BUILD, BUILDROOT, SPECS。然后以 foo(假设软件包名称为 foo) 在SPECS目录里新建一个 spec 文件。


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


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


使用Koji的前提是,打包者必须是Fedora官方的软件包维护员,即Fedora Packager CVS Commit Group已验证的成员,并且把相关的管理员证书安装好。需要安装的是3份证书。
<pre>rpmbuild -ba foo.spec</pre>
第一份,从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-upload-ca.cert
保存好后,运行


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


随后生成一份fedora-browser-cert.p12证书,你可以把这份证书添加到浏览器中,那么就可以通过浏览器登录koji的web界面。使用koji来测试软件包的命令如下
<pre>
rpmlint pkgname.spec
rpmlint pkgname.src.rpm
rpmlint pkgname.i586.rpm  // 若该软件包是i586架构的。
</pre>


koji build –scratch targets pkgname.src.rpm
关于本地打包,可参考 RPM 打包教学 https://fedoraproject.org/wiki/Zh/Docs/RPM%E6%89%93%E5%8C%85%E6%95%99%E5%AD%B8


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


koji list-targets
== 使用 Mock 和 Koji 去测试 RPM 包 ==


== 在bugzilla上发布软件包审核请求(Package Review) ==
=== Mock ===


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


软件包进入Fedora官方源之前需要通过严格的审核。软件包通过了完整的审核流程,确保质量上完全没有问题才可以进入Fedora的官方源。作为一名没有被sponsored的打包者,你的软件包审核申请必须被Sponsor查阅,审核并通过。当这个软件包通过审核流程以后,Sponsor往往要求你再提交一到两个软件包的审核申请,当这些软件包都有审核通过的时候,Sponsor就会认可你的打包能力,
安装好 Mock 以后,即可馬上使用:
正式批准你成为Fedora的软件包维护者(Package Maintainer)。只有你成为正式的软件包维护者,你才有权限去维护和更新你申请的软件包。如果你已经是Fedora的维护者,你的新软件包申请只需要高级维护者通过(Proven Packager)即可。


软件包审核请求的例子可参阅:https://bugzilla.redhat.com/show_bug.cgi?id=493246
<pre>mock -r <configfile> rebuild pkgname.src.rpm</pre>


Bugzilla的页面上,在Component项选择Package Review;在URL项上则填上软件包的项目主页地址;在CC上填入申请者的有效邮件地址;在Summary上,则填入 Review Rquest: foo--(一句话介绍)。关键点在Description上,你需要提供一个spec文件和一个src.rpm文件的下载地址.方便审核者查看和审阅。另外,申请者还需也要提供一份关于软件包的较为详细的介绍。然后,就在最后点击Commit的按钮。
(<configfile> 是位于 /etc/mock 里面,配置文档的名称;只需要輸入文件名,扩展名必须省略。)


审核需要等待数日才会有Sponsor去参与审核你的申请。而审核的标准,则是这一份Package Guideline https://fedoraproject.org/wiki/Packaging:Guidelines (请求翻译者翻译)。如果你的申请出现问题,审批者会要求你重新提供修正后的spec文件和src.rpm文件.这里可能要花费一段时间。当Sponsor批准你的申请以后,你申请CVS空间来存放软件包的代码和spec文件。回到Bugzilla的页面,把fedora-cvs的flags改为“?”并且在新的comment输入CVS申请的信息。里融资如下
因为要从源服务器上下载大量的 rpm 包以模拟编译环境;所以 Mock 的执行会耗费比较多时间。如果网络连接速度不是很快的朋友,建议不要使用这种办法,或者可以参考通过建立本地源的办法加快下载速度 http://fedoraproject.org/wiki/Docs/Drafts/MockSetupUsingLocalMirror 。若是在 Mock 通过测试,则大抵可以说这个软件包足够稳定了。


New Package CVS Request
=== 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
 
保存好后,运行如下命令:
 
<pre>fedora-packager-setup</pre>
 
RPM Fusion 的是如下命令:
 
<pre>rpmfusion-packager-setup</pre>
 
随后生成一份 fedora-browser-cert.p12 证书,你可以把这份证书添加到浏览器中,那么就可以通过浏览器登录 koji 的 web 界面。因为 RPM Fusion 仍然使用 Plague,因此运行 rpmfusion-packager-setup 是不会有 p12 证书生成的。RPM Fusion 计划未来会跟随 Fedora 转用 Koji,但没有公布具体时间表。
 
使用 koji 来测试软件包的命令如下,RPM Fusion 资源所限,禁止使用 Scratch Build:
 
<pre>koji build --scratch targets pkgname.src.rpm</pre>
 
查看 targets 可以通过以下命令:
 
<pre>koji list-targets</pre>
 
关于 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 申请的信息。內容如下:
 
<pre>
New Package SCM Request
=======================
=======================
Package Name: pkgname
Package Name: pkgname
Short Description: summary of package
Short Description: summary of package
Owners: foo bar
Owners: foo bar
Branches: F-10 F-11 EL-5
Branches: f14 f15 f16 el6
InitialCC: baz
InitialCC: baz
</pre>
* "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 空间存放相关文件。
<pre>
Package CVS request
======================
Package Name:
Short Description:
Owners:
Branches:
InitialCC:
----------------------
License tag: [free|nonfree]
</pre>
RPM Fusion 的 SCM 申请最后增加了 License Tag,表示该软件是进入 Free 还是 Nonfree 软件仓库。
== 汇入软件包代码到 Git 服务器 (Fedora)==
自 Fedora 14 开始,Fedora当 Git 管理员把 fedora-cvs 的 flags 改为”+”的时候,表示线上的 Git 已完成建立,第一次使用 Git 建议在 ~/rpmbuild 里建立 GIT 目录方便管理:
<pre>mkdir -p ~/rpmbuild/GIT</pre>
进入 GIT 目录,你就可以在本地计算机上检出 (checkout) Git 分支:
<pre>fedpkg clone pkgname</pre>
完成后,请把获批准的 src.rpm 包汇入 Git 服务器。先进入 Git 目录,假设你的软件包是放在 $HOME 里,执行以下命令:
<pre>fedpkg upload ~/pkgname.src.rpm</pre>
维护者可以根据每个 Fedora 版本分支 (branch) 逐个上传,默认是在 master 分支是指向 Rawhide,Fedora 16 的分支是 f16。上传完成后,就可以在 koji 上编译打包你维护的软件包。
提交更改:
<pre>git commit</pre>
填写 Changelog 以后把修改的内容上传到 Git 服务器:
<pre>git push</pre>
把 Git 上传的内容同步到本地计算机:
<pre>git pull</pre>
然后开始编译打包:
<pre>fedpkg build</pre>
每一个更新理应每一个分支,如果每一个分支更新的内容不一样,请在每一个更新上重复以上步骤。如果是一样,在完成以上步骤以后,
首先切换分支:
<pre>fedpkg switch-branch f16</pre>
<pre>git checkout f16</pre>
合并分支到 master (假定 f16 分支和 master 分支的内容是一致的):
<pre>git merge master</pre>
把更改的内容提交到 Git 服务器:
<pre>git push</pre>
把 Git 上传的内容同步到本地计算机:
<pre>git pull</pre>
然后开始编译打包:
<pre>fedpkg build</pre>
注意:编译打包并不是在本地计算机上进行,而是在远程服务器进行的,所以在编译打包过程中并不会占用你的系统资源。但是由于网络延迟的关系,有时候需要很长时间才能从远程服务器反馈信息到本地计算机;然而终端信息显示与否,绝不影响远程服务器编译进度。
== 推送软件包更新到 Bodhi (Fedora) ==
当编译完成后,终端会反馈出编译是否出错,同时你的邮箱就会得到一份邮件较为详细的报告。倘若非 devel 分支的编译打包成功,则需要把软件包推送到 bodhi 。bodhi 有命令行和网页界面两种方式,一般推荐使用网页界面的操作。登入 Bodhi https://admin.fedoraproject.org/updates/ 之后,点击 New Updates,新建一个更新请求。然后在Package 项输入要申请的软件包名称,版本号,隶属的分支,格式一般为:
<pre>shutter-0.80.1-2.fc11</pre>
* 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 服务器,建议在上传成功后就马上删除此文件:
<pre>fedpkg upload pkgname.tar.gz</pre>
然后把修改过的 spec 文件,其余与编译有关的文件添加到提交序列,例如程序补丁,图标,徽标等:
<pre>
git add pkgname.spec
git add packagename-fix-the-foobar.patch
git add sources
</pre>
提交更改的内容并填写 Changelog:
<pre>git commit</pre>
如果增加和修改的文件比较多,可以直接用以上命令提交,无须逐一文件添加到序列:
<pre>git commit -a</pre>
把更改的内容推送到 Git 服务器:
<pre>git push</pre>
更新本地分支的文件:
<pre>git pull</pre>
设置编译器构建软件包:
<pre>fedpkg build</pre>
最后还是需要像新软件包那样把更新推送到 bodhi。使用以下命令可以方便地把更新推送到bodhi:
<pre>fedpkg update</pre>
如同上文所述,软件包维护者应当切换到不同的分支为不同的 Fedora 版本提供更新。一般而言,每一次更新都是用相同的源代码包给不同的 Fedora 版本,因此源代码包上传一次即可。sources 文件是记录和校验源代码包,应当在提交更改的时候附上。
当 Fedora 发布新版本的时候,维护者应当进入 Git 目录同步新的分支到本地:
<pre>git fetch</pre>
在没有完成提交过程的时候,Git 是不允许使用者切换分支的。此时可以先暂存更改的代码,在完成其他分支的工作后继续修改。暂存时:
<pre>git stash</pre>
回来时:
<pre>git stash apply</pre>
== 汇入软件包代码到 CVS 服务器 (RPM Fusion) ==
当 CVS 管理员批准了 Packager 的 CVS 请求的时候,这表示线上的 CVS 已完成建立,你就可以在本地计算机上检出 (checkout) CVS 分支。第一次使用 RPM Fusion CVS 需要配置相应的环境变量:
<pre>
mkdir -p ~/rpmbuild/CVS
export CVSROOT=:ext:username@cvs.rpmfusion.org:~/rpmbuild/CVS/
export CVS_RSH=ssh
</pre>
* username 是 Packager 在 RPM Fusion FAS 上的 ID。
如果你不想每次开机都重新设置,可以把以下两项命令加入到 ~/bashrc:
<pre>
export CVSROOT=:ext:username@cvs.rpmfusion.org:~/rpmbuild/CVS/
export CVS_RSH=ssh
</pre>
从 RPM Fusion Free 检出 CVS 分支的是:


<pre>rpmfusion-free-cvs pkgname</pre>


== 汇入软件包代码到CVS服务器 ==
RPM Nonfree 的是:


<pre>rpmfusion-nonfree-cvs pkgname</pre>


当CVS管理员吧fedora-cvs的flags改为”+”的时候,你就可以在本地计算机上建立CVS分支。
完成后,请把获批准的 src.rpm 包汇入 CVS 服务器。先进入CVS目录,假设你的软件包是放在 $HOME 里,执行以下命令:


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


建立完成后,则可以把获批准的src.rpm包汇入CVS服务器。进入CVS目录,假设你的软件包是放在$HOME里
维护者需要根据每个 Fedora 版本分支 (branch) 逐个上传,F-11 对应的是 Fedora 11 的分支,而 devel 则对应的是 Rawhide 的分支,以此类推。上传完成后,就可以在 koji 上编译打包你维护的软件包。


./common/cvs-import.sh -b F-11 -m "import Joe's update" ~/pkgname.src.rpm
首先把CVS上传的内容同步到本地计算机:


维护者需要根据每个Fedora版本分支逐个上传(Branch),F-11对应的是Fedora 11的分支,以此类推,而devel则对应的是Rawhide的分支。上传完成后,则可以在koji上编译打包你维护的软件包。
<pre>cvs up</pre>


首先把CVS上传的内容同步到本地计算机
然后开始编译打包:


cvs up
<pre>make build</pre>


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


make build
== 更新已有的软件包 (RPM Fusion) ==


和把软件包汇入到CVS服务器一样,你也需要逐个进入每个发行版的分支来编译打包。注意: 编译打包并不是在本地计算机上进行,而是在远程服务器进行的,所以在编译打包过程中并不会占用你的系统资源。但是由于网络延迟的关系,有时候需要很长时间才能从远程服务器反馈信息到本地计算机,因此你并不可以不关闭正在远程编译的终端。
当软件包更新到新的版本以后,维护者有义务更新软件库内的版本。一般的维护者只能维护自己申请的软件包和获得维护权的软件包。作为维护者,你可以使用像新软件包的办法把 src.rpm 文件汇入到去 CVS 服务器后编译来更新软件包,而以下则是介绍另外一种办法。


更新前,Packager 需要配置相应的环境变量:


== 推送软件包更新到bodhi ==
<pre>
export CVSROOT=:ext:username@cvs.rpmfusion.org:~/rpmbuild/CVS/
export CVS_RSH=ssh
</pre>


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


当编译完成后,终端会反馈出编译是否出错,同时你的邮箱就会得到一份邮件较为详细的报告。倘若编译打包成功,则需要把软件包推送到bodhi。bodhi有命令行和网页界面两种方式,一般推荐使用网页界面的操作。登陆入Bodhi https://admin.fedoraproject.org/updates/之后,点击New Updates,新建一个更新请求。然后在Package项输入要申请的软件包名称,版本号,隶属的分支,格式一般为
如果你不想每次开机都重新设置,可以把以下两项命令加入到 ~/bashrc:


shutter-0.80.1-2.fc11
<pre>
export CVSROOT=:ext:username@cvs.rpmfusion.org:~/rpmbuild/CVS/
export CVS_RSH=ssh
</pre>


Type为newpackage;Request为testing;Bugs为审核申请在Bugzilla的ID;Notes则为简要地介绍软件包内容。随后则可以电机Save Update。这里需要审核的过程,大约几天的时间。审核过程中管理员还会在Koji重新编译软件包,并在打包的时候添加GPG密钥。当审核通过的时候,软件包就会出现updates-testing的软件库里。此时你需要把Request改成stable,如果维护者早前在Bugs里输入了ID,Bugzilla则会自动关闭改审核申请。当软件包通过最后的审核,则会出现在updates上,整个新软件包审核流程就会结束。
把新软件包的源代码压缩包放置在 Fedora 分支的目录里,然后上传到 CVS 服务器:


另外devel分支的软件包无需推送到bodhi,就会直接被推送到rawhide的软件库。
<pre>make upload FILES=”pkgname.tar.gz”</pre>


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


== 更新已有的软件包 ==
<pre>cvs add packagename-fix-the-foobar.patch</pre>


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


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


首先把新软件包的源代码压缩包放置在Fedora分支的目录里,然后上传到CVS服务器。
提交维护者对软件包更改的内容:


<pre>Make upload FILES=”pkgname.tar.gz”</pre>
<pre>cvs commit</pre>


然后把其余与编译有关的文件上传到CVS服务器,例如程序补丁,图标,徽标等。
标记软件包版本,注意:标记的版本号是根据 spec 文件里维护者所表示填写的版本号,这个版本号必须要比之前的要更高,否则在编译的时候会出现版本号问题:


cvs add packagename-fix-the-foobar.patch
<pre>make tag</pre>
确保所有被更改的部分完整正确


cvs diff -u
设置编译器构建软件包:


提交维护者对软件包更改的内容
<pre>make build</pre>
cvs commit
标记软件包版本,注意:标记的版本号是根据spec文件里维护者所表示填写的版本号,这个版本号必须要比之前的要更高,否则在编译的时候会出现版本号问题。


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


设置编译器构建软件包
* 本页面最后更新于 2011 年 9 月 13 日。


make build
[[Category: 指南]][[Category: 教程]]
最后还是需要像新软件包那样把更新推送到bodhi。
[[Category:Zh]]
[[Category:Zh/OS]]

Latest revision as of 06:37, 13 September 2011

前言

本文旨在解说软件包维护的概括流程,使中文地区一些英文能力稍逊的 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 密钥。

查询你要打包的软件是否已经存在于 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 日。