1. 软件包准入checklist
| 检查点 | 说明 |
|---|---|
| 归一化 | 1、原则上一款软件只在deepin-community中引入一次。 |
| 来源可靠 | 1、开源软件都应该从开源软件官网获取或官网指定的代码托管地址获取。 |
| 规范化软件名称 | 1、 软件名称必须和官网/社区保持一致，不可随意命名， 2、 不允许以软件包中的子模块作为软件名， 3、 当软件是某个语言的开发库时，我们允许追加python-、perl-等前缀予以规范化管理。 |
| 社区运营状态检查 | 1、软件来自知名社区或组织，社区或组织通过发布公告、修改软件仓库状态、将仓库放到特定目录下等方式告知停止维护的，不建议引入， 2、软件来自个人、小型社区或组织，两年内未发布版本（含正式版本与测试版本），无明确版本计划，社区提交了有效的Bug或PR，但是半年以上未响应的，不建议引入， 3、社区运营状态不明确，通过Issue 或者邮件等方式询问社区是否继续维护，半年以上未响应或者答复停止维护的，不建议引入。 |
| 官网必填 | 1、软件官方网址填写规范，使用软件供应商提供的网址，或者无单独正式官网的情况下，提供主流代码托管商上面对应的项目网址如github 2、不能使用maven、mvnrepository、springsource等托管库作为官方网址 |
| 软件包信息提供 | 1、必须提供官方提供的源代码包的下载地址，以达到可溯源 2、如果有需要二进制包，需要提供官方的二进制包下载地址 |
| license检查 | 1、待引入软件是否有license 2、入库时填写的license是否和官网保持一致；是否和软件包中license保持一致；高风险license的开源软件谨慎引入 |
| copyright检查 | 1、通过官网、社区、代码托管网站、源码包、发布件中等地方获取并提供copyright信息 |
注意事项：
2.1 使用apt工具分析运行依赖是否满足
2.2 构建依赖
若上游项目自带debian目录：
根据自带的control rules等文件查询待引入的把构建依赖
分析自带的rules postinst等脚本是否存在兼容性问题，如存在则建议整改后向上游提交PR
若需引入的软件包未提供debian目录：
根据软件包构建 中说明生成的debian目录
原则上任何引入deepin社区的软件包在提交PR前均需要对其进行完整的依赖分析和自验证。