Contrib: 通用 openSUSE 第三方软件安装源

设想/我们需要什么

当前的 OBS 构建服务第三方软件供应模型复杂而难用。在交错的成百个 OBS 项目中分布着大量的软件包，这不免带来了麻烦和问题。软件安装源之间不容易相互切换浏览，而且有很多重复的软件包，而且也没有专门测试过是否可用。正真的解决方法是将所有这些软件包都放到车间里面。现在这还不是一个可选项，因为对于车间中的一个软件包来说，必须要有一个 Novell 雇员作为维护人员来保证更新。

我们的目标是建立通用第三方软件安装源。该源将被看作社区所驱动的车间的扩展，而所有的标准和限制也将被照搬。

规则/我们做什么

基本上 Contrib 的规则和车间的差不多，比如最终发布期限等等。

安装源规则

所有软件包必须在 openSUSE 或该软件安装源的软件包的基础上进行构建。
源上软件包不能和车间的重复
该安装源在 openSUSE 发布的时候作为分支扩展 (openSUSE:Factory:Contrib -> openSUSE:<version>:Contrib)
- 在分支扩展声明之后，所有软件包版本号马上冻结，不再作更新。
- Bug 修正以补丁形式发布到对应软件包。

软件包规则

每个软件包必须有一名维护人员来做维护工作:
- 软件包更新
- 维护软件包(修正 Bug，上游处理 Bug 等等)
- 安全更新 (SuSE 安全小组会提供帮助)
- Beta 阶段进行 Beta 测试
软件包需要通过 Contrib 审查
不能与车间的包有任何的(文件)冲突

许可/谁来做

为了保证上述规则的执行，我们需要一套针对软件源及其中软件包的权限许可。因此我们需要包含两个角色。一个是维护员：负责维护单个或更多的软件包；另一个则是复审员：负责维护软件源本身。

openSUSE:Factory:Contrib

该软件源归属复审员
- 新软件包的提交经由 osc submitreq 处理并进行初始复审。
- 软件源 Bug 管理员: opensuse-contrib@opensuse.org
软件包归属复审员
- 软件包上的开发工作进行，没有附加复审。
- 软件包 Bug 管理员: 维护员

openSUSE:<version>:Contrib

该软件源归属复审员
- 无新软件包
- 软件源 Bug 管理员: opensuse-contrib@opensuse.org
软件包归属复审员
- 所有事物归 osc submitreq 处理并进行全面复审
- 软件包 Bug 管理员: 维护员

步骤/怎么做

有二选一的实现: osc-contrib 命令。

openSUSE:Factory:Contrib 新软件包

某打包者 Joe 要维护在 Contrib 软件源中的软件包 foo
Joe 在他在源上的主目录(或者其他有写入权限的地方)中创建软件包
Joe 试图向 Contrib 构建软件包并检查依赖关系或项目配置文件中的个人设置是否有问题：

osc build --debug --alternative-project openSUSE:Factory:Contrib standard [<arch>]

在打包者 Joe 认为他的软件包已经足够完善的时候，他利用 OSC 向 Contrib 软件源发送提交请求：


 $ osc submitreq create X11:windowmanagers blackbox openSUSE:Factory:Contrib blackbox -m "add blackbox"

这时一封邮件将会发送至 opensuse-contrib@opensuse.org (内容和这个差不多: http://en.opensuse.org/User:Hennevogel:Tmp)
一名 Contrib 审查员将向邮件列表发送邮件，声明他将负责该审查过程 (锁定软件包，这样可以使我们避免重复工作)
Contrib 审查员或者通过该请求


 $ osc submitreq accept 6001 --message="reviewed ok. You are now maintainer of foo in Contrib"

或者回绝该请求


 $ osc submitreq decline 6001 --message="Sorry. Declined. Fix the Factory build errors first. If you need help lets talk on opensuse-contrib :)"

最后一步，审查员将原始提交者设置为该软件包的维护员及 Bug 管理员


 $ osc meta pkg -e openSUSE:Factory:Contrib blackbox
 <person userid="jpack" role="maintainer"/>
 <person userid="jpack" role="bugowner"/>

openSUSE:Factory:Contrib 中软件包的 Bug 修正

打包者 Joe 从 openSUSE:Factory:Contrib 签出 (Check out) 软件包


 $ osc co openSUSE:Factory:Contrib blackbox

Joe 完成修改后将软件包签入 (Check in) 软件源


 $ osc ci -m 'fixed bug in init script'

openSUSE:<version>:Contrib 中软件包的 Bug 修正

打包者 Joe 从 openSUSE:<version>:Contrib 派生出软件源


 $ osc branch openSUSE:11.1:Contrib blackbox

Joe 现在便能够从他的分支区域签出并使用软件包进行工作了


 $ osc co home:jpack:branches:openSUSE:11.1:Contrib/blackbox

一旦 Joe 认为他已经修正了 Bug 问题，他便可以提交软件包


 $ osc ci -m "fixed serious bug"

所有东西都构建完毕后，Joe 再次向 openSUSE:<version>:Contrib 发送提交请求


 $ osc sr create -m 'fixed serious bug'

一封邮件将被发送至 opensuse-contrib@opensuse.org (内容看起来像这样: http://en.opensuse.org/User:Hennevogel:Tmp)
一名 Contrib 审查员向邮件列表作回复，声明他将负责审查工作 (锁定软件包，这样可以避免我们重复工作)
Contrib 审查员或者通过该请求


 $ osc submitreq accept 6002 --message="reviewed ok. Update is released"

或者回绝该请求


 $ osc submitreq decline 6002 --message="Sorry. Declined. There is another buffer overflow in main.c line 155"

openSUSE:<version>:Contrib 中软件包的安全 Bug

与上文相同，唯一的区别就是 Bug 报告者将会是 SuSE 安全小组

邮件列表/和谁交流

我们的列表是: opensuse-contrib@opensuse.org

请查看邮件列表页面以学习大概如何订阅及处理 openSUSE 邮件列表。

常问问题 FAQ

Q: 我们需要一个 contrib-(staging|beta|unstable|experimental|testing) 软件源吗，以存放在进行中的报告测试完成之前的软件包 ?
A: 总体来说，较之将软件包寄存在上游或用户 OSB 目录而不是 Contrib中，我们更倾向于保留使用 unstable/experimental 之类的。软件包稳定后便可以发送整合请求。

Q: 请定义发行循环周期 (冻结、发布声明等等)
A: "Contrib" 会和车间发布循环周期同步。将会在 openSUSE 开发循环周期内以及里程碑循环周期内和它一起进行软件包开发工作。车间代码的冻结同样会影响到 "Contrib" 。

Q: Contrib 软件源在哪呢?
A: 安装源的基本目录在此: http://download.opensuse.org/repositories/openSUSE:/Factory:/Contrib/

Q: 如何在我的 openSUSE 中添加 Contrib 软件源呢 ?

A: openSUSE 11.1 用户请使用:

 zypper ar http://download.opensuse.org/repositories/openSUSE:Factory:Contrib/openSUSE_11.1 openSUSE:Factory:Contrib:openSUSE_11.1

A: openSUSE 车间版用户请使用:

 zypper ar http://download.opensuse.org/repositories/openSUSE:Factory:Contrib/standard openSUSE:Factory:Contrib

Q: 可是我不喜欢车间版，它老是不断更新。这里难道不是一个漏洞吗?
A: 不是那样的，Contrib 是为 openSUSE 11.1 构建的, 因为我们需要一个更容易采纳和测试的 Contrib。但是考虑到车间版 (11.2) 才是主要的目标，因此这并不是一个漏洞，只是其他构建目标。

Contrib

Contents