更新 开始贡献/openKylin源码自主选型构建流程.md 文档

+ 新增对control文件的版本号依赖修改规范

开始贡献/openKylin源码自主选型构建流程.md

@@ -336,6 +336,71 @@ admin, cli-mono, comm, database, debug, devel, doc, editors, education, electron
 
 对于**Build-Depends**和**Build-Depends-Indep**可以从项目地址中查找是否有相关编译依赖说明。
 
+---
+**注意：** 如果control文件参考了其他OS发行版的规则，需要去除或替换其他OS版本中的版本号规则，例如：
+
+```
+Build-Depends: 
+  pkg1 (>= 1.0.0-0ubuntu1), 
+  pkg1 (< 1.2.0-1debian2),
+  pkg2 (> 1.0.0.build),
+  pkg3 (> 2.0ubuntu19)
+```
+
+首先，需要明确对于quilt格式的版本号其一般带有"-"，格式为`<upstream_version>-<revision>`，而native格式的源码包一般不包含"-"
+
+修改流程可以分两步进行
+
+**第一步：**
+
+对于quilt格式的版本，pkg1中的版本号 1.0.0-0ubuntu1 和 1.2.0-1debian2 其包含特定OS发行版的版本号，因此要修改。也就变成：
+
+```
+pkg1 (>= 1.0.0), 
+pkg1 (< 1.2.0),
+```
+
+对于native格式的版本号，首先需要确定其upstream版本，对于pkg2和pkg3：
+
+（1）尝试找到pkg2的1.0.0版本，如果能找到，那么1.0.0就是upstream版本，其编译依赖改为：pkg2 (> 1.0.0)；同理pkg3
+
+（2）如果找不到pkg2的upstream版本，此外当前版本号没有包含其他OS发行版名称，那么可以保留（因为使用source-package工具重打包源码，其upstream版本号也就是当前的版本号）；但是对于pkg3，如果pkg3是OS自研的（其源码名称一般也包含OS名称，例如ubuntu-keyring），那么此时可以将此包重新改名，由openkylin重新维护，对应源码名称改为openkylin-keyring，版本号也重新制定，例如可以制定为1:1.0.0；如果不是OS自研包，最好我们也重新制定版本号，按我们自己的版本号去维护，可以内部讨论，例如这里也指定为1:1.0.0。**注意这里，最好要使用:格式的版本号，其表明带有:的版本号总会比不带的版本号高。**
+
+那么，对于pkg2，pkg3，其修改为：
+
+```
+pkg2 (> 1.0.0.build),
+pkg3 (> 1:1.0.0)
+```
+
+**第二步（native格式的不用处理）：**
+
+第二步是在第一步的基础上改进。总体上我们要明确其他OS发行版中-横线后面的修订版本的内容。
+
+对于<upstream_version>-<revision>，一般来说每个revision是修复了某个bug、安全漏洞等。对于ubuntu，每个revision都是由几个patch组成。
+
+因此对于pkg1 (>= 1.0.0-0ubuntu1)，其明确规定是0ubuntu1修订版本之后的才能使用，也就意味着使用pkg1的1.0.0版本是存在风险的，最直接的现象就是编译不通过。
+
+因此，这就需要结合我们实际的pkg1的版本情况来：
+
+（1）如果仓库存在pkg1，其版本为1.0.0-ok1。为了保证上述编译能通过，需要集成ubuntu的1.0.0-0ubuntu1中的patch。如果已经集成相关patch，那么编译依赖就变成：
+
+```
+pkg1 (>= 1.0.0-ok1), 
+pkg1 (< 1.2.0),
+```
+
+集成了patch之后仓库中的pkg1版本变为1.0.0-ok2。那么在编译依赖的地方就变成：
+
+```
+pkg1 (>= 1.0.0-ok2), 
+pkg1 (< 1.2.0),
+```
+
+（2）如果仓库不存在pkg1，那么我们首次自主选型构建时，选型的版本最好是在1.0.0~1.2.0 之间选择，保证能满足各个依赖包的编译依赖。
+
+上面所说，都是基于编译依赖来处理。同理二进制包的安装依赖字段如果也指定了版本号，那么处理方式也是和上面的一样。
+
 #### 3.1.2 二进制包部分
 
 描述当前源码包可以被分为哪些二进制包程序。