From Fedora Project Wiki

Revision as of 19:31, 17 August 2009 by Liangsuilong (talk | contribs) (Created page with 'Fedora新维护人员指南 == 前言 == 本文旨在提供一个简易的办法,使中文地区的Fedora包管理员能够更方便地去管理软件包,并且希望能...')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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的软件包维护人员,则需要拥有一个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查询该软件包是否已经存在。如果存在,则无需要为该软件制作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在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 foo.spec rpmlint foo.src.rpm rpmlint foo.i586.rpm //若该软件包是i586架构的。


使用Mock和Koji去测试rpm包

使用Mock的好处是显然意见的,因为Mock是建立了一个沙盘模式以确保BuildRequire内容的正确性。 安装好Mock以后,即可使用

mock -r <configfile> rebuild foo.src.rpm

<configfile>位于/etc/mock里面,配置文档的名称。

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


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

fedora-pcackager-setup

随后生成一份fedora-browser-cert.p12证书,你可以把这份证书添加到浏览器中,那么就可以通过浏览器登录koji的web界面。使用koji来测试软件包的命令如下

koji build –scratch targets pkgname.src.rpm

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

koji list-targets

在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的页面上,在Component项选择Package Review;在URL项上则填上软件包的项目主页地址;在CC上填入申请者的有效邮件地址;在Summary上,则填入 Review Rquest: 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


汇入软件包代码到CVS服务器

当CVS管理员吧fedora-cvs的flags改为”+”的时候,你就可以在本地计算机上建立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

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