openEuler 软件引入策略原则
版本
-
2020-01-11 Initial Draft by Xinwei Hu
-
2020-01-21 Integrate input from Liang Chengye, Wang Lingzhuo, Guodong Xu and Yang Li
目录
关于本文档
目标
openEuler是一个致力于创建开放操作系统的合作组织。我们希望openEuler-
尽可能集成多的软件组件
-
鼓励所有人使用openEuler，并可以在openEuler上开发软件
-
使能任何人，在不违反license，进出口管制或其他相关法律的前提下，可以容易的制作安装介质
openEuler遵从 Open Source Definition ，满足这一定义的软件，被openEuler社区认同为开源软件。
提供适度，高质量的开源软件是openEuler主要目标之一。openEuler努力为其所提供的开源软件在生命周期内提供高质量的支持服务。开源软件自由众多，质量不一。本着提供高质量开源软件的宗旨，特别拟定本规则指南。本规则的中必须，必须不能，应该，应该不能的含义参考rfc2119。
范围
本文档定义了openEuler软件包所需要遵从的策略要求。所以提交到openEuler的软件包需要满足本手册中定义的技术要求。本文的改进和修订说明
-
本文档由openEuler技术委员会 （Technical Committee）主导起草和维护。本文档的最新版本总可以在 XXXXXX [URL] 上找到。
-
所有对本文档的修改意见可以通过邮件列表 XXXXX 反馈和讨论。 任何对于本文中涉及的规则的增加，修改，删除都必须被追踪，请进入该追踪系统 。
-
最终规则的经过充分的讨论后，由技术委员会定稿。
软件选型、选型规则及引入原则
什么是软件选型
一个软件的选型指的是一个软件(项目)从用户库被申请引入到官方库，依照本文件描述的规则讨论，进而满足规则要求，最终引入官方库的过程。
整个引入的过程都必须可被追踪。目前 https://gitee.com/src-openeuler/openEuler-repos/issues 是这个过程的追踪系统。
软件选型规则的适用范围
选型规则约束一个软件(项目)是否可以被引入到src-openeuler.yaml文件中，并在src-openeuler中作为一个目录维护。
注意：升级一个官方库中已存在的软件包不是软件选型，所以不在本规则的覆盖范围内。
软件包进入选型的两个基本前置条件
凡是需要引入到openEuler的开源软件(项目)，必须有唯一的ID。这个ID是openEuler中管理开源项目的元数据库中的唯一标识。
-
第一步：在元数据库中创建一个item。
-
第二步：以元数据库的ID做为标识来讨论的软件(项目)。
openEuler软件包引入原则
为实现对软件生命周期的维护和管理，基于证据的可信贯穿于选型的整个过程。在一个软件包被引入的每一步都需要有记录，这些记录被作为可信过程的存证。
-
一次必须只能引入一个软件。
-
软件应该有明确的引入理由。
-
软件应该是开源软件，开源软件的定义参考https://opensource.org/osd.html 。如果非开源软件，经由technical committ讨论后决定。
-
软件应该是源码包，原则上二进制不应该被引入。如果需要引入二进制，经由Technical Committ讨论后决定。
-
原则上，该软件应该在openEuler上可以被正确构建。当软件有尚未被引入的依赖关系，或者软件的运行或者构建依赖一个绝不可能引入openEuler的组件，此等例外，经由Technical Committ讨论后决定。
-
原则上，openEuler不引入rootkit或者其他类似存在可信问题的软件。
-
存在于黑名单的软件必须不能引入。
-
每一个软件的引入决定，都作为案例，作为后续类似软件引入决策的参考。Technical Committ对软件引入原则的一致性负责。
黑名单机制
Technical Committ讨论后，可以将被拒绝引入的软件被记录到一个软件黑名单，作为证据减少重复劳动。
https://gitee.com/src-openeuler/openEuler-repos/software-blacklist.md
元数据
元数据的存储
鉴于目前openEuler采用RPM作为包管理系统，同时考虑到对元数据的需求，本规则定义的元数据需要考虑兼容RPM SPEC的前提下作为单独的一份文件存储于RPM SRC包中。所有的软件包都应提供其元数据信息，该信息需符合以下openEuler软件包元数据定义的模板要求。
注意：该独立的文件名字是meta.json，并采用json的数据格式。
元数据库中的 Identification
目的
唯一识别该软件
强制性
- 必须
作用
引入的软件必须有唯一的ID。ID可以用来描述不同软件包之间的关系，所以ID的唯一性很重要。
格式
RPM SPEC
Name: openssl
RPM 包的名字，在整个REPO具有唯一性，可以作为ID。
Json ORG style
org id, 代表该软件包项目的组织ID，类似namespace的作用。
art id, 代表该项目的ID
json的表达格式实例
"id": {
"org": "org.openssl",
"art": "openssl"
}
推荐，如果同时提供RPM SPEC的方式和Json ORG style两种，应该考虑名字的一致性。
元数据库中的 主页地址
目的
一个开源项目的真正的实质。它和ID在一起作为元数据库中跟实际项目的binding。
不同的ID的项目应该不能一样。一个项目只能由一个官方主页。
强制性
- 必须
格式
RPM SPEC
URL: https://www.openssl.org/
JSON style
软件包的 主页地址，任何一个开源软件都需要有一个主页，如果没有正式的官方主页，那可以认为软件的发布页为主页，比如github的项目主页。
json的表达格式的实例
"official": "https://www.openssl.org/"
元数据库中的 REPO地址
目的
保存该开源项目的repo地址。可以有多个。
强制性
- 可选
格式
JSON style
"repo": [
"git://git.openssl.org/openssl.git",
"https://github.com/openssl/openssl.git"
]
元数据库中的 LANG
目的
说明该项目使用的主要编程语言。
强制性
- 可选
格式
JSON style
"lang": [
"c"
]
元数据库中的 TAG
目的
说明该项目主要的应用领域的其它属性。
强制性
- 可选
格式
JSON style
"tag": [
"protocol",
"tls"
]
元数据库中的 LISENCE
目的
说明该项目用来描述该项目使用的LISENCE，LISENCE需要使用SPDX定义的ID。
强制性
- 必须
格式
JSON style
为兼容SPDX，使用来自SPDX标准的命名。
"lisence": [
"SPDX-License-Identifier: OpenSSL"
]
元数据库中的 项目关系
目的
说明该项目用来描述该项目之间关系。这个关系可用分析项目直接的关系，其中requires的关系可以直接推导出运行时的依赖关系。
强制性
- 可选
格式
RPM SPEC
Requires: coreutils perl ca-certificates crypto-policies
JSON style
为兼容SPDX，使用来自SPDX标准的命名。
"related": {
"HAS_PREREQUISITE": ["org.gnu.coreutils", "org.perl.perl", "ca-certificates", "crypto-policies"]
}
软件(项目)关系的定义列表见附件
选型过程 request
每次选型如果的请求都应该被记录，都应该可追溯。
https://gitee.com/organizations/src-openeuler/issues
requester
提出该次选型入库申请的申请人。该申请人应该是被申请包的作者。
reason
申请的理由，描述这个软件(项目)为什么应该存在于官方的repo中。
result
描述这次选型入库的申请是否通过。
取值
-
accepted 应该有reason。
-
rejected 应该有reason。
附带软件的选型入库
引入一个软件有可能附带引入其它软件(项目)，根据一次引入一个软件的原则，分别为每个软件提交请求，并且附带软件的引入原因需要体现被附带引入这个情况。
软件是否存在于公开的语言库 TODO
比如 Marven，PIP，Python，NPM，Ruby等等，
如果有应该提供在所在语言库的链接。
项目关系列表
为兼容SPDX，使用来自SPDX标准的命名。
| relation | description |
| -------- | ------------|
| HAS_PREREQUISITE | 该软件需要其它的软件支持其运行，所有的被依赖软件都应该被列举。 相当于 RPM SPEC中 Requires |
| PREREQUISITE_FOR | 该软件支撑了其它软件的运行，不能被完全列举。 |
| HEEDS_BUILD_TOOL | 该软件构建时需要那些软件的支持。相当于 RPM SPEC 中 BuildRequires |