目录

• 1. 综述
  • 1.1 文档范围
  • 1.2 术语定义
  • 1.3 修订记录
• 2. 软件包管理基础设施介绍
  • 2.1 软件包在代码仓库的位置
  • 2.2 代码分支管理
• 3. 软件包引入
  • 3.1 软件包引入基本原则
  • 3.2 闭源软件引入规范
  • 3.3 版本选型原则
  • 3.4 SPEC 规范
  • 3.5 开源软件引入流程
  • 3.6 闭源软件引入流程
• 4. 软件包构建
  • 4.1 自验证构建
  • 4.2 正式构建
• 5. 软件包发布与变更
  • 5.1 软件包发布原则
  • 5.2 软件成熟度划分和变更流程
  • 5.3 Anolis OS 软件包仓库结构
  • 5.4 软件包发布流程
• 6. 软件包删除
• 附录1
  • 附录 1.1 软件包引入申请模板
  • 附录 1.2 社区重点生态应用场景
  • 附录 1.3 软件包发布需求模板
  • 附录 1.4 发布单模板

304 龙蜥社区软件包引入和管理原则

1. 综述

1.1 文档范围

本文档涵盖：

• 龙蜥社区产品发布 SIG 成员在引入或维护 RPM 软件包时需遵循的准入原则及操作流程；
• 龙蜥社区开发者及各 SIG 成员将 RPM 引入 Anolis OS 发行版时需遵循的准入原则及操作流程。

本文档不涵盖：

• 源码引入原则及操作流程。源码引入到龙蜥社区是另外的话题，需要单独向龙蜥社区技术委员会申请；
• 软件包引入规则的原理解析；
• 软件包引入时 RPM SPEC 的编写细节。

本文档的维护主体为龙蜥社区技术委员会，文档定稿或重大修改均需报请技术委员会审议，通过后施行。

1.2 术语定义

在本文描述中，软件包代码在仓库中的组织形式分为两种，分别为「source tree」和「rpm tree」。

• 「source tree」 是指项目源码本身，在 Gitee 中以源码协作开发的方式维护，并按照软件自身研发节奏发布对应的 release，供其他社区或者爱好者进行下载使用，本文档不涉及 source tree 的组织与管理；
• 「rpm tree」 是用于龙蜥社区构建发行版和 SIG 组构建产品对应的软件包的代码树，通常包含 rpm spec 文件 + 包含源码的 tarball，可用于后续构建和发布。这部分软件按照软件的成熟度分别放在对应不同的 Gitee 仓库。

1.3 修订记录

2. 软件包管理基础设施介绍

龙蜥社区使用 Gitee 管理 Anolis OS 发行版及所有 SIG 组的软件包代码，统一放在 https://gitee.com/openanolis 组织下。

2.1 软件包在代码仓库的位置

此处展示使用较为频繁的几个软件包仓库的信息：

2.2 代码分支管理

对于 rpm tree，每个软件仓库会通过特定分支进行进一步统一管理，确保不同的 OS 版本都有对应分支可映射；在初始化仓库时，应该建立对应版本的分支，后续将代码提交 PR 通过 review 后合入到对应分支上。

3. 软件包引入

软件包引入由申请人发起，申请人可以是产品发布 SIG 组成员，也可以是其他 SIG 组对应软件包的 owner（以下统一称为「软件包负责人」）。

3.1 软件包引入基本原则

软件包负责人需明确软件包引入原则，不符合软件包引入原则的组件，不允许引入。软件包引入的原则包含三大原则：

• 背景和用途：能给出引入背景和软件用途，并阐述带来的业务场景和价值
• 软件维护责任：软件引入时，需要同时声明软件包的负责人，并承担起维护的责任，包括：修复 bugfix、修复 CVE、更新等动作
• 引入责任规范：必须满足下面所有的引入要求，达到合规状态的软件才允许引入

3.2 闭源软件引入规范

闭源组件主要针对不想公开源码、仅公开二进制的场景，龙蜥社区允许这部分特殊软件通过闭源方式引入，并提供 epao-nonfree 仓库作为闭源组件的 repo 源公开使用。 闭源组件除了需要满足上述 「3.1 软件包引入原则」的基本原则外，还需要满足如下规范：

3.3 版本选型原则

龙蜥社区的软件选型主要围绕「分层分类」理论展开，根据软件包对操作系统发行版的重要程度，以及整体应用场景模块化程度，设立不同的选型原则。

• 优先级上参照「分层分类」理论中的分层思想，从层级优先级高的软件包开始重点制定和维护策略；
• 场景上参照「分层分类」理论中的分类思想，按应用场景维度分割，模块化地分批引入软件包；

3.4 SPEC 规范

详细规范请参阅 Anolis OS 23 spec 规范。
下列情形需严格遵守该规范编写 SPEC 文件：

• Anolis OS 23 及以后的发行版引入的所有软件包；
• Anolis OS 7, Anolis OS 8 中新引入的软件包。

下列情形可参考本规范，并不强制执行：

• Anolis OS 7 和 Anolis OS 8 中现存的软件包。

3.5 开源软件引入流程

1. 引入条件审查：软件包负责人需根据 「3.1 软件包引入原则」 和 「3.2 版本选型原则」所载明的规范要求，明确软件包的代码符合要求、版本选型符合规范，同时明确软件包的演进和维护路线。
2. 提交软件包引入申请：软件包引入涉及发行版基线变更，基线数据是通过社区的软件包集成项目 (ospkg-list) 管理的。每一个软件包都需要通过 Pull Request 提交引入意向申请。该申请将由产品发布 SIG maintainer 负责审阅，必要时报请技术委员会成员审阅，如通过后则完成软件包基线数据的变更。
   1. 如果软件包在 ospkg-list 里不存在，则需要参照「附录1.1 软件包引入申请模板」填写一个新的 {package}.yaml文件。申请通过后由产品发布 SIG maintainer 创建新的仓库和对应分支；
   2. 如果软件包在 ospkg-list 里已经存在，则无需提交新的 {package}.yaml，在现有软件包数据中添加新的字段即可。申请通过后由产品发布 SIG maintainer在现有仓库创建新的分支。
3. 本地验证：在本地进行软件包的构建和安装验证，保证基本功能正常。
4. 提交软件包代码：根据 「305 SPEC 规范」制作符合要求的 rpm tree 代码，并提交 PR 到对应的软件包分支中。
5. 完成引入: 产品发布 SIG maintainer，必要时社区技术委员会指派成员，根据 review 规范审核对应的 PR，如通过后则完成软件包整体引入。其他 review 结果包括：打回修改，拒绝等。如拒绝则需给出明确的理由。

3.6 闭源软件引入流程

1. 引入条件审查：软件负责人根据「3.2 闭源软件引入规范」所声明的规范要求，明确软件包的代码形式、License 符合规范，同时明确软件包的演进和维护路线。
2. 联系法务人员，保证二进制开源合规：软件维护者需要联系软件提供厂家的法务人员，一般要申请两个纰漏流程，包括二进制披露和开源代码合规扫描，完成流程审批。
3. 提交软件包引入申请：同 「3.5 开源软件引入流程」中的提交申请步骤相同，在 (ospkg-list) 发起申请，按照模版填写清楚背景（包括闭源原因）、收益、维护者、维护方式、License 类型等基本信息。
4. 建立代码仓库和分支：发行版同学在接收 ospkg-list 申请之后，进行评估，评估通过之后，会进行建立代码仓库、建立分支操作。
5. 提交代码：软件维护 owner 按照 308 闭源软件集成样例 将二进制提交，并发起 pr，等待门禁 CI 的运行结果
6. 合并代码和正式构建： 待 maintainer 审核通过后，由发行版同学负责正式构建和发布。
7. 用户安装使用：待软件发布到 epao-nonfree 源之后，需要先安装 anolis-epao-nonfree-release 包，再通过 yum install 方式安装闭源组件。

4. 软件包构建

软件包构建从构建目的角度可以划分为两种：自验证构建和正式构建。

4.1 自验证构建

该过程为开发者自行在本地或模拟环境中对软件进行构建，以验证软件包本身的构建能力或产出测试包供后续测试。目前推荐的方式有两种：

• 本地通过 mock 机制构建，参考《Anolis OS 8 软件包本地构建 · 语雀》一文；
• 通过 Anolis Build System (ABS) 提供的个人工作空间机制进行自定义构建，可以参考《使用ABS平台轻松胜任Anolis OS开发工作》 一文的内容，进行构建。
• 构建过程中遇到的问题参考 「306 rpmbuild 构建指导手册」

4.2 正式构建

正式构建的产物将会发布到对应的 Anolis OS 发行版本中，因此需要慎重操作。正式构建操作需要通过命令行操作，并且需要提前获得相关 token，请联系龙蜥社区发 布小组 maintainer 获取相关 token。

5. 软件包发布与变更

5.1 软件包发布原则

软件包发布指的是将通过正式构建流程生成的二进制推送到镜像 YUM repo 中。发布时会根据 ospkg-list 工具中的软件包基线数据信息，推送到对应的 YUM repo 中。
软件包经过正式构建得到 RPM 产物后，并不能直接发布，需要经过 abs 系统集成的 CI 流程后，由产品发布 SIG maintainer 执行软件包签名，之后推送 YUM repo 并生成发布单(Errata)。

5.2 软件成熟度划分和变更流程

OpenAnolis 龙蜥社区中将所有的软件划分成三个阶段：系统包、成熟包、孵化包。

5.3 Anolis OS 软件包仓库结构

根据 「3.1 软件包引入原则」 和 「5.2 软件成熟度划分和变更流程」中的分层机制，OpenAnolis 龙蜥社区将所有软件按照如下 YUM 仓库 进行管理，分为三大类：系统包、成熟包、孵化包。

5.4 软件包发布流程

1. 经过正式构建得到候选发布(release candidate)包，abs 自动执行集成的 CI 流程，如未自动执行，则可在 abs 系统手工触发；
2. 通过所有 CI 测试项，或手工确认失败项无影响后，则达到发布条件。在 Bugzilla 平台 提交软件包发布需求，模板参考「附录 1.3 软件包发布需求模板」；同时需填写发布单(Errata)，如有多个软件包，则只需填写一个发布单即可，模板参考「附录 1.4 发布单模板」。
3. 产品发布 SIG maintainer 确认通过发布需求，分别执行软件包签名、推送 YUM repo、生成发布单操作，如软件包达到系统包级别，则还需额外更新镜像 comps 文件。

6. 软件包删除

当某些开源软件不再符合 OpenAnolis 的规范时，需要将其从社区中删除。目前已知条件如下，持续更新：

附录1

附录 1.1 软件包引入申请模板

name: my_packages
repository: https://gitee.com/src-anolis-sig/my_package
summary: a short description
rpm_owner: anolis-bot
branches:
- name: a8
  repo: epao
  maturity: rawhide
- name: a23
  repo: epao
  maturity: rawhide

附录 1.2 社区重点生态应用场景

• 数据库
• 云原生
• Web Server

附录 1.3 软件包发布需求模板

申请发布

1. 背景 必填: 简单描述需求背景, 有必要可以提供相关公共链接
2. 用户故事 必填: 说明用户, 业务/应用场景, 获得结果/收益, 价值/竞争力/优势等
3. 重要性/优先级 选填: 说明该需求的重要程度, 优先级, 紧迫性等
4. 目标/计划 选填: 说明该需求目标版本或预期日期等
5. 依赖/影响 选填: 说明该需求开发, 测试相关依赖信息及工作量估计
6. 验收标准 选填: 说明交付物, 预期效果等

附录 1.4 发布单模板