openSUSE:Packaging Patches guidelines
构建服务教学 - 技巧和花样 - 跨发行版打包 - Debian 打包指南 - 打包检查
桌面菜单分类 - 打包常用的 RPM 宏 - 小脚本片段 - SysVinit 脚本 - 源代码服务
OBS 打包互助问答 - 打包黑名单
补丁标记
为了方便使用自动化工具，和接手的打包者，我们约定使用如下的补丁类别：
- Fixes: 这些是普通的修复，分成两类：
- 针对 openSUSE 的修复，上游开发者对此不感兴趣。
- 针对 SLES 企业版的修复，上游开发者对此不感兴趣，且不能被 openSUSE 使用。
- 针对上游源码包的修复，这些补丁接着会被提交给上游。
- Features: 添加给软件包的新特性，同样分成两类：
- 针对 openSUSE 的新特性 (比如 AppArmor 整合)，上游开发者对此不感兴趣。
- 针对 SLES 企业版的新特性，上游不感兴趣，openSUSE 也得不到好处。
- 应该提交给上游的新特性。当我们开发这样的特性时，应该和上游开发者互动。这样，我们就能开发出一些无需更改上游就能接受的特性。一旦一个特性没和上游开发者互动就做出来，那得重写好多东西才能让上游开发者满意。因此，最好先了解一下上游开发者期待什么特性。
为了使我们的补丁满足上述约定，我们发展出了一套 标准 来在 .spec 文件中标记它们，格式如下：
# PATCH-FIX-OPENSUSE fix-for-opensuse-specific-things.patch [bnc#123456] Patch1: fix-for-opensuse-specific-things.patch # PATCH-FIX-SLE fix-for-sle-specific-things.patch [bnc#123456] Patch2: fix-for-sle-specific-things.patch # PATCH-FIX-UPSTREAM fix-for-upstream-sources.patch [bnc#123456] Patch3: fix-for-upstream-sources.patch # PATCH-FEATURE-OPENSUSE feature-for-opensuse-specific-things.patch [bnc#123456] Patch4: feature-for-opensuse-specific-things.patch # PATCH-FEATURE-SLE feature-for-sle-specific-things.patch [bnc#123456] Patch5: feature-for-sle-specific-things.patch # PATCH-FEATURE-UPSTREAM feature-for-upstream.patch [bnc#123456] Patch6: feature-for-upstream.patch
特别注意：我们经常临时的注释掉一些补丁因为它们不能应用到最新的源码上，也就是说这些补丁需要重写。不要注释掉补丁的声明，而是注释掉它的应用。当一个补丁需要重写时，最好在它前面加上 old- 前缀。
# PATCH-NEEDS-REBASE（补丁需重写） old-补丁名.patch [bnc#123456] -- 过时了。曾经是：PATCH-FEATURE-OPENSUSE Patch7: old-补丁名.patch [...] # %patch7
最后我们要加入电邮以识别补丁作者，方便后续维护，在 "--" 之后随手写注释。
例如:
# PATCH-(FIX|FEATURE)-(OPENSUSE|SLE|UPSTREAM) 补丁名.patch bnc#[0-9]* 你的电邮@example.com -- 这个补丁做了点特流掰的事。
若是在 Novell 或其他的 bugzilla 有相关的 Bug，请添加它们，这能方便我们得到更准确的信息。如果有两个以上，那么最好都列出来。
你可以在文档底部找到目前的缩写列表。如果有必要我们未来也会定义更多的缩写。
有些补丁修复了别的地方没有记录的漏洞和错误。在这种情况下就取决于打包者的判断了，下面是一些参考：
- 如果马上就要新版发布了，那么去提交臭虫报告。这通常是必须的，即使不必须，也是应该做的事。
- 如果新版要等很长时间才发布，这个臭虫已经被上游除掉了，添加注释说已在 SVN (或其他) 里修复，本补丁下次升级将作废。
补丁命名
所有的新补丁都应该以 '.patch' 后缀结尾。
补丁的名字是否要以它补缀的软件包名开头仍存争论，这其实是个风格问题。当有疑问的时候，该软件包的其他补丁是怎么命名的你就怎么命名。
不要使用在 Patch: 标签里使用 %{version} 宏，手动指定版本号。使用该宏：
- 会造成版本升级时你需要手动重命名那些补丁，因为补丁是硬编码名称的独立文件。
- 不方便找出那些针对旧版本的不再适用的补丁。
- 不方便知道补丁内容的最后修改日期，因为你不断的重命名了它。
- 补丁出错时不方便排错。
一个特例是：修复编译器发现无用代码抛出的警告的补丁，通常命名为 'abuild.patch'。
推崇的补丁的路径忽略层级一般是 -p1，因为它使得使用诸如 quilt 这样的工具引入显得更直观。
目前可用的缩写
为了避免混淆和双倍负担，引用其他 Bugzilla 是允许的。下面是一些常用 Bugzilla 的缩写，可以放在 Bugzilla ID 的#号之前。注意#号前后都没有空格。
其他的 Bugzilla ID，请在补丁头部使用 URL 全址。比如：
缩写的书签小工具
使用 bnc# 前缀搜索 bugzilla.novell.com 的书签小工具可以在 这里找到。