软件包管理原则

1. 文档说明

OpenCloudOS Stream是OpenCloudOS社区的L1上游版本，是OpenCloudOS社区L2商业版本、L3社区版本的基础，软件包来之上游原始社区。

本文档对OpenCloudOS Stream软件包管理原则进行说明，帮助OpenCloudOS社区开发者、版本使用者更好地了解OpenCloudOS软件包的引入、维护、退出、选型等方面的要求、规范、策略。

2. 软件包管理基础

软件包从源码到编译构建到RPM REPO，主要涉及以下基础设施： - 源码仓库：OpenCloudOS Stream的软件包源码仓库在 opencloudos-stream 组织下。 - 编译构建：通过koji进行编译构建。 - RPM REPO：通过OpenCloudOS社区网站的下载进入。

REPO当前由三部分组成，后续根据需求会考虑增加其他REPO： | REPO名称 | REPO说明 | | --- | --- | | BaseOS | 存放OS基础软件包rpm，OS标准软件包的一部分 | | AppStream | 存放开发、应用、工具等软件包rpm，OS标准软件包的一部分 | | EPOL | 存放扩展软件包rpm，不作为OS标准软件包保证漏洞修复、兼容性等的支持，主要通过升级方式维护 |

新引入软件包默认先进入EPOL，后续根据需求、维护策略等可以调整到AppStream。

当前Stream项目只有一个master分支，后续启动新的major版本研发时会拉分支，分支命名体现版本名字，如Stream27。

3. 软件包引入

3.1 软件包引入说明

软件包引入是申请将一个OpenCloudOS Stream项目中不存在的开源软件在OpenCloudOS Stream项目下创建源码仓库，通过编译构建、验证最后进入RPM REPO。

3.2 软件包引入原则

软件包引入需要满足下面的基本原则，不满足原则的软件包不允许引入。 - 软件包必须有明确的上游维护地址或者官网地址，不允许引入来源不明的软件包，原则上不引入无社区或者开发者维护的软件包。 - 软件包必须从源码构建，原则上不允许引入二进制文件。 - 软件包内容必须遵守法律法规、社会公德、民族习俗等，不允许引入可能有法律风险、或者引起不适的软件包。 - 软件包必须有明确的License和Copyright声明，不允许引入存在License风险、专利风险的软件包，不允许引入商业闭源软件。 - 软件包应该说明引入的必要性，包括但不限于背景、原因等。 - 软件包应该考虑唯一性，原则上一个软件包只引入一次，如有特别情况需要引入软件包多版本，必须说明引入必要性。 - 软件包应该考虑漏洞情况、生命周期情况等，存在严重漏洞未修复、或者已经EOL的软件包不建议引入，如需引入，需要明确维护策略。

3.3 软件包引入操作

软件包引入操作，详见OpenCloudOS Stream 上游版本贡献指南。

软件包打包指导，详见软件包打包指导

4. 软件包维护

4.1 软件包维护方式

软件包维护是对项目中引入的软件包在版本的维护周期内，进行漏洞修复、bug修复、质量加固/补充用例、输出使用文档以及打包SPEC优化、增强开发等一系列活动，确保提供的软件包安全、稳定、可靠、合规，能够满足生产或者开发的要求。

软件包的维护主要有2种方式： - 以补丁方式维护，包括backport上游社区的补丁、引入其他发行版的补丁、社区自定义补丁，通常用于对兼容性要求较高、变化后影响范围大的核心包和基础包。 - 以升级方式维护，通过升级到上游社区新版本来解决问题或者引入功能，通常用于对兼容性容忍度较高、变化后影响范围小的应用软件等偏上层的软件包。

4.2 软件包兼容性等级

OpenCloudOS社区当前考虑定义以下3个兼容性等级： - level 1：在一个major版本周期内原则上保持API/ABI兼容，若有变化，需要说明原因和必要性。 - level 2：在一个minor版本周期内原则上保持API/ABI兼容，若有变化，需要说明原因和必要性。 - level 3：不保证API/ABI兼容。

根据软件包的分层以及用户需求等，综合考虑制定软件包的兼容性等级（制定中）。 OpenCloudOS社区会通过在CI中落入兼容性检查、差异对比等工具来看护软件包的变更。

4.3 软件包维护周期

软件包维护周期，如无特别说明，一般跟随版本生命周期。Stream版本的维护周期，在下一个major版本发布后结束。对于提供多版本的软件包或者由于突发情况（如License变更后有风险、社区不再维护等）需要退出的软件包，根据维护策略，单独声明维护周期。

5. 软件包退出

软件包退出是一个软件包不满足OpenCloudOS的软件包规范要求，从项目中删除。

5.1 软件包退出原则

当软件包处于以下情况时，必须将软件包立即从项目中退出： - 软件包的License、Copyright等信息发生变化或者闭源、转商用等，导致可能存在法律风险 - 软件包存在恶意代码或者严重安全隐患，且无法修复

当软件包处于以下情况时，需要规划将软件包有序从项目中退出： - 上游社区不再维护，或者持续长时间无版本发布、无代码提交和讨论 - 软件包功能不再需要，退出后无影响 - 软件包架构或者实现落后，有其他同类软件可以替代

5.2 软件包退出操作

软件包退出操作，详见OpenCloudOS Stream 上游版本贡献指南.

6. 软件包选型

软件包在引入、通过升级方式进行维护时，都涉及软件包选型，通过分析软件包上游社区的活跃情况以及软件包本身情况，确保引入高质量的软件包。

6.1 软件包选型原则

软件包选型的考虑因素，除了软件包引入中的原则外，还需要关注以下方面： - 上游社区活跃，包括版本发布、issue/pr数和处理及时性、贡献者数等，尽量选择活跃的社区。 - 选择正式发布的版本，原则上不允许选择RC版本等非正式发布的版本。 - 选择相对稳定的版本，新功能开发提交频繁、发布频繁的软件包，不能一味追求新版本，特别是需要周边软件适配的软件包，如python、boost等，需要选择已经发布一段、周边的模块包或者软件包已经适配完成的版本。 - 选择维护周期长的版本，部分多分支的软件包有明确的维护周期声明，结合版本的维护周期选择与版本维护周期匹配度比较好的版本。 - 结合软件包维护策略，选择满足兼容性等要求的版本。