openSUSE talk:打包帮助
好多新手的提问都会涉及到 rpmlint 的 error/warnings。所以解释下什么是 rpmlint。它是一个检查最终生成的 RPM 包中的常见错误的一个小工具。默认对 OBS 的本地编译和服务器编译开启。本地编译会返回到你的命令行; 服务器编译会在包主页的 openSUSE_12.1 success字样的链接点进去后的 rpmlint.log 的最后部分。
而 rpmbuild 则是指 RPM 建包的主程序。
常用缩写 OBS,本身是 Open Build Service,也即 开放式构建服务。
目录
问答列表(Q&A)
如何找到正确的开发源?
初始打包者:
首先了解下为发行版做贡献的流程。如何为发行版做贡献
然后 osc 的用法可以在 openSUSE 开放式构建服务教学 和 『玛噶学姐带你学 OBS』(二)OBS 常用命令:以创建一个包为例 中找到。
- openSUSE:12.1:Update 这样带有发行版戳记的叫做用户源,是供用户使用的。只有 maintanance 维护操作才可以改动它,因此不要直接 branch 开它的分支,那样自己用可以,是提交(commit)不回去的。
- openSUSE:Factory 是下一个版本的 openSUSE 的集中编译源,它只接受完美的最终提交,也不是开发源。
- DISCONTINUED: 开头的源是太过老旧而官方不再支持的废弃源。它的作用在于让用户有地方装老软件,而不是给开发者使用的。
- 带 Maintanance 的源是维护源,用来向稳定的如 openSUSE:12.1:Update 中推送给用户的更新。
- 以 Dropped(掉落,很形象) 结尾的源是长时间没人维护的包所在的源,如果你想捡起来维护它中的包,可以 copypac 到你的 home,然后 对它做 deleterequest。
完整的开发源列表在 公开源列表(注意,这里的公开源不是公众源,是公开的可以被开发者使用的源,用户也可以用,但风险自负),本列表中不满足上面的条件的源和以 devel 开头的源都可以被视为开发源。
一些源名称里带上了特殊的关键词,如 windows:mingw:win32 这就是给一小部分满足条件的软件用的开发源,不满足条件不要往里面提交。另外一些源有特殊性,需要点击开看源的描述 description,比如 KDE:Apps,GNOME:Apps 或 games 就是不随发行版更新,而是自己有着自己的更新周期的源,这样的源中的软件就不能被提交到 openSUSE:Factory,也不需要,做发行版时 auto build 团队会过来自己取。再比如 openSUSE:Factory:Contrib 这个源,虽然名称没说,但是事实已经废弃了,提交时审核团队会告诉你。你可以把软件从这个源中 copypac 到自己的 home,然后提交给 Factory 后,deleterequest 这个源中的相应软件,这样慢慢的这个源就消失了。
补丁提交者: 在 openSUSE 软件搜索 中能够搜索到的源都是用户源,点击进入 OBS,先看软件包的 information 里是否有 developed at xxx 的字样直接提示你开发源,如果没有看看是否有 x derived packages 字样,点它,开发源一般都在里面了。如果两样都没有,那么它就是可以直接用作 branch 开分支然后继续开发的。
- MargueriteSu 2012年4月14日 (六) 02:07 (MDT)
不再用的开发源是否要删掉?
OBS 提供的开发资源是免费的,但不是无限的。首先它有一个 打包黑名单,其次 adrianSuSE 会有定期清理,3 个月无活动的子项目,1 年无活动的 home 都会被定期清理掉。
其次当你开通了 home,你就是你自己 home 的 bugowner(臭虫回报指定人),也就是你要收臭虫。这样就会有用户以 3rd-party-software 这个 section 在 novell bugzilla 上给你提交 bug。一个不再维护的源收到 bug,是挺滑稽的。
所以你编译成功的源,可以留着给用户一键安装或加源安装(adrian 清理的时候会在 打包邮件列表 里发帖,到时候回帖让他不要删就好了,订阅邮件列表的方法在 交流方式 页面); 编译失败/弄错的源一定不要让它存在。麻烦会很多。
- MargueriteSu 2012年4月14日 (六) 02:49 (MDT)
如何为 openSUSE 的包制作补丁? 补丁的授权是怎样的?
普通的补丁制作:
- 下载源代码包,比如 sourcecode.tar.bz2,解压开。
- 复制 sourcecode 目录到 sourcecode.orig 目录。
- 在 sourcecode 目录中做出相应的文件修改。注意要记得删除掉 sourcecode~ 这样的 kwrite 缓存文件。
- 回到 sourcecode 的上层目录。运行:
diff -urN sourcecode.org sourcecode > 补丁名.patch
就得到了补丁文件。
- 然后在 spec 文件里通过 Patch1: 补丁名.patch 引入
- %prep 准备章节中使用 %patch1 -p1 来打上。
openSUSE 的独特之处在补丁的命名上,有一个前缀:
- 修复 openSUSE 的就是 fix-for-opensuse-; SLES 的就是 fix-for-sles-; 上游的就是 fix-for-upstream-
- 添加新功能同上,只不过是 feature-for
然后在 spec 中引入补丁的那行前面要添加一行注释来解释下补丁是做什么的。格式如下:
PATCH-(FIX|FEATURE)-(OPENSUSE|SLE|UPSTREAM) 补丁名.patch bnc#[0-9]* 你的电邮@example.com -- 这个补丁做了点特流掰的事。
其中补丁名.patch 和 bnc#7497 两个条目可选。bnc 是 bugzilla.novell.com 的缩写,其他缩写和关于补丁的详细内容请见 补丁指南。
补丁不用在乎谁是原作者,默认与包的源代码协议一致; 若补丁自有协议,作者一般会把自己的联系方式和协议内容写在补丁里。上面注释中的电邮只是说明这个补丁是谁加上去的,后续维护应该找谁。
- MargueriteSu 2012年4月14日 (六) 04:27 (MDT)
non UTF-8 specfile?
这是因为有些外语用户的母语的字母在 unicode 字符集之外,所以他为了正确显示自己的名字还是怎样,就把 .changes 的 changelog 文件以 ISO 8859 的格式保存了。而 .changes 文件会被 OBS 在打包的时候归并到 spec 文件的 %changelog 章节下面去,因此导致了这个错误。这也提示了我们中文用户不要使用 GBK/GB2312/Big 5 这样的编码来保存文件。
另外 spec 和 .changes 文件请不要使用中文。这只有在语系设为中文的 YaST 中才能够看到。
解决方案不是修 spec,而是下载 .changes 文件,将那个人的名字重新用英文字母替代。然后保存为 UTF-8 后上传。
另外 openSUSE 的开发源中(你的 home 中对这个的要求比较低,但也请建立一个哪怕是空的 .changes 文件而不是把变更记录直接写在 spec 里),每次修改都必须写 changelog。本机的 osc 是使用 osc vc(这个命令能够运行的前提是要有 spec 文件在该目录。),服务器是点击 files 下面的 .changes 文件,然后点击 insert changes entry template 插入新条目。具体的格式请参考 spec 文件指南里面的 changelog 章节。
拿到一个 specfile 首先应该做什么?
- 首先使用 vim 打开它。
vim *.spec
然后看看它有没有版权头部,就是 2012 SuSE 这样的字样在头部。如果没有的话,先拉到最下面看看它有没有把 changelog 写在 spec 里面,如果有的话,你需要手动建立一个 .changes 文件,把 spec 里的变更记录以 openSUSE 的格式重制。
- 然后应该运行:
osc service localrun format_spec_file (需要安装 osc-format-spec-file 包)
这样会把你从别处取得的 spec 文件给用 openSUSE 的格式标准来跑一下,添加版权头部,把 BuildRequires 按字母顺序排序等等。
- 再跑一下:
spec-cleaner -i *.spec(需要安装 spec-cleaner,都在 openSUSE:Tools 源)
这会清理一下 spec 文件中的无用内容。
- 删除 spec 文件中的 #no-root-for-build 注释和 %clean 章节,新版本的 OBS 会自动做这些,不需要再写明。
- 检查 %if 0%{?suse_version} > 1020 这样的字段,该字段具体的解释在 跨发行版指南,把 1020 这样的 openSUSE 官方不再支持的版本号替换成目前尚在支持的最低版本,比如目前是 1140。
- 检查 $RPM_BUILD_ROOT,使用 kwrite 的替换功能将它替换成 %{buildroot},这是 openSUSE 标准宏,而前者是 RPM 标准宏,关于两者的区别请见 spec 文件指南。
无法移除源或者包
这样的源或者包一定是被别人开了分支或者链接(linkpac)了。openSUSE 不直接存储所有的文件到分支中,而是在分支中以文件软链接的形式指向母体,只有你变动了文件才会在分支源中保存实体。这样就意味着实际上你的源或包的内容还有另外的所有者。作为母体,你需要让所有者都取消它们对母体的链接,你才能删除母体。
比如有人发给你了 open request,你去看一下,审核通过,这样对方的 branch 就会被删除。如果没有 open request,你应该邮件分支的主人(电邮地址点他的用户名可以看到),告诉他你删除该源/包的原因,问他是否还要继续做开发,不开发请删除他。如果他还继续开发,而你这边不是开错了源或者上游不再维护,准备从 openSUSE 中 drop 这个包,只是编译错误你搞不定的话,等等他或许会有意外惊喜哦。
新的问题
新的内容