软件包的构建，对于操作系统来说，是一件根底且十分重要的事件。以后的 Linux 操作系统生态中，不同的发行版打包形式也有不同的体现。本文整顿自龙蜥大讲堂技术直播第二期，以龙蜥社区发行的龙蜥操作系统为例，来开展讲述对于 rpm 包构建的一些内容。
一、Linux 操作系统常见的软件包治理形式
操作系统实际上就是一个大的软件汇合，成千盈百个软件之间有互相调用、相互依赖等各种简单的关联关系。所以对立的软件包格局，可能更敌对地治理、定义这些简单关系。
在 Linux 操作系统中常见的软件包格局有：以 redhat 为代表的 rpm 系列、和以 debian 为代表的 deb 系列（如图 1）。
图 1 常见两种软件包格局示例
通过图 1 能够直观的看到，以 .rpm 为扩展名的 rpm 系包，与以 .deb 为扩展名的 deb 系列包，同一套源码包应用不同的打包工具，在各自的环境中，是能够打包出这两种格局的软件包的。
.rpm 应用 rpmbuild 系列命令，配合 spec 文件打包。
.deb 应用 dpkg 系列命令，配合 control 文件打包。
大部分开发者在 Linux 中习惯应用 tarball 来散发软件，不是也能够编译装置吗？当然能够，然而 tarball 编译装置的形式相比应用打包编译好的 rpm，或者 deb 来说，治理上就没有那么不便，操作也更简单。所以咱们心愿，更多的开发者，将本人的源码 tarball 可能打包公布到操作系统软件源中，或者将源码奉献到龙蜥社区。
不论是 rpm 还是 deb。在不同 Linux 发行版里都是为了更好的治理、散发软件。
二、龙蜥操作系统的软件包组织模式
龙蜥操作系统基于 redhat 开发，也应用 rpm 来治理。
图 2 rpm 包信息示例
如图 2 左，rpm -ql 命令，能够直观的看到 systemd-libs 这个包的文件目录构造、装置门路。
如图 2 右，rpm -qi –provide 可能看到包名称、release 号、版本号等根底信息，加了—provide 参数将他本人所提供的符号、库等信息打印进去，十分具体、高深莫测，命令也不简单，所以，显然比 tarball 编译装置更不便一些。
三、操作系统之软件资源管理
图 3 软件资源管理
对操作系统这样的基础性系统软件来说，它的性能总体分为硬件治理和软件治理。咱们说软件包格局定义了软件资源管理形式，那软件资源管理是什么？软件资源又蕴含哪些？
如图 3，软件资源包含各种零碎程序、各种应用程序、各种用户程序，也包含大量的文档资料、库函数等。每一种软件资源自身都是具备肯定逻辑意义的相干信息的汇合，在操作系统中它们以文件模式存储。
艰深的说就是：这些软件对应的动态文件放在哪里，装置在哪个目录，库函数调用的门路等等？例如一些 man 手册、.so 文件等、可执行文件如何存储，这些就是软件资源管理所定义的内容。
在某种意义上来说，在操作系统中，软件资源管理就依靠于软件包来实现。咱们从软件包打包的角度来体现操作系统软件资源管理。
图 4 文件系统档次简图
龙蜥操作系统的文件系统档次就是一个很好的例子，图 4 中的目录调配，根据 FHS（文件系统档次）规范。曾经定义好了那就依照规定开发，当然，针对 FHS 规范，各个发行版也有些差别，
FHS 仅定义了最上层 根目录及根目录下一层 的目录内容应该要搁置的文件或目录数据，因而，在其余子目录层级内，就能够依据开发者诉求来配置。举个列子，centos 网络配置放在 /etc/sysconfig/network-scripts/ 目录，但 suse 将网络配置放在 /etc/sysconfig/network/ 下，所以有不同的目录名称，然而只有遵循 FHS 规范，差异性其实无限。
对于 FHS
FHS（Filesystem Hierarchy Standard）：是 Linux 爱好者自发的组成的一个个人，次要是是对 Linux 做一些根本的要求。
FHS(http://www.pathname.com/fhs/) 的官网文件指出，他们的次要目标是心愿让使用者能够理解到已装置软件通常搁置于那个目录下，所以他们心愿独立的软件开发商、操作系统制作者、以及想要保护零碎的用户，都可能遵循 FHS 的规范。也就是说，FHS 的重点在于标准每个特定的目录下应该要搁置什么样子的数据而已。这样做益处十分多，因为 Linux 操作系统就可能在既有的风貌下 (目录架构不变) 倒退出开发者想要的独特格调。
事实上，FHS 是依据过来的教训始终在继续的改版，FHS 根据文件系统应用的频繁与否与是否容许使用者随便更动，而将目录定义成为四种交互作用的状态，如表 1：
表 1 FHS 交互作用定义表
图 5 系统目录性能调配简图
目录层级定义好了，该看看目录性能的调配，包含每个区域的用处、所须要的最小形成文件和目录，图 5 就包含了这些目录的功能性。
随着操作系统的一直倒退，咱们发现根底的 rpm，还会有些性能上的不不便，咱们的发行版个别提供的软件版本只会有一个次要版本，然而这个版本有时候不能满足开发者须要，他们依据本人的理论状况可能须要更高、或更低的版本来撑持他们的开发，这就须要开发者本人再做构建，或者应用第三方的、非官方提供的软件仓库。这点让开发者节约了很多工夫。所以，新的个性，——module 来了，就是为了解决这个问题。
Module 是一个模块化包，但它不像非模块化包那样只是一个 rpm 文件，它代表一个或多个 rpm 包和元数据文件的汇合，这些文件是模块构建过程的产物。一个模块的元数据能够定义多个 rpm 文件和模块，它们被捆绑并装置在主机零碎上。作为 rhel8 系列公布的 rpm 包治理新形式，Anolis 同样反对和利用在了目前曾经正式公布的所有 Anolis8 系列操作系统中。
Module 其实是对 rpm 的再次治理，通过对次要包的不同版本的依赖关系进行细分，以 module 为单位，所以，module 其实是个汇合，我集体通常把它了解为组。一个 module 组。然而官网的命名称之为“流”（stream）。
Anolis 每个版本仅提供一个受反对的次要软件版本。这意味着如果您须要本人应用不受反对的版本，则必须本人构建它或依赖某个非官方存储库。上面的例子能够更好地阐明这种状况：
场景 1（图 6）
一些用户装置来自不同 Anolis 版本的软件包，以便应用与其应用程序兼容的特定版本的数据库。但多亏了模块化，他们可能不再须要这样做了，因为在每个 Anolis 版本中都能够应用多个版本的数据库。他们所须要做的就是间接从 Anolis 存储库为他们的零碎应用该数据库的特定流。
图 6 postgresql module
场景 2（图 7）
在某些状况下，用户无奈将系统升级到新的 Anolis 版本，因为他们的应用程序无奈在降级后的语言运行时的新版本中运行。模块化能够通过在两个 Anoils 版本中提供雷同的语言版本来解决这个问题。这样，用户能够应用特定的语言流并在降级零碎时保留它。当应用程序筹备好应用新语言版本时，它能够在当前独立于操作系统进行降级，通过切换到不同的流（stream）。
图 7 python 多版本 module
总的来说，龙蜥操作系统中应用 rpm 来治理软件包，同时提供了 module 这样的个性来更敌对的撑持对软件版本有不同需要的开发者和用户。
四、分析 rpm 包构建
图 8 rpm 构建工具集关系图
构建工具集
Spec 文件
Spec 文件是构建 rpm 包的外围定义，应用 spec 文件配合其余构建工具即可打包 rpm。
Rpmbuild
rpmbuild 是最根底的构建工具，它对 spec 文件进行解析和执行。
Mock
依据软件依赖创立污浊构建环境构建 rpm 包的工具。
Koji
Rpm 包编译构建零碎。
咱们在后面讲到的软件资源管理，外面波及到的文件寄存地位的定义，存哪些文件内容，这些就间接在 spec 文件中体现。之前的规定就是用来帮忙咱们编写 spec 文件的，也就是编译规定。咱们把软件编译办法、编译命令、装置门路、各种文件应该被放在哪里，一字不落的在 spec 文件中定义进去，让源码依据咱们所指定的形式来构建出可执行安装文件。所以，spec 文件是 rpm 包构建的规范束缚。
咱们在本地构建个别间接应用 rpmbuild。通常咱们为了构建出不受零碎环境影响的 rpm 包，应用 mock 工具来构建，它与 rpmbuild 不同的点仅仅在于，它能够创立一个专门用于编译的污浊环境，它仅装置用于编译的那局部依赖包及必要的编译器和编译工具，所以 mock 能够用不同的软件仓库构建软件包，也就是说能够指定模仿不同的编译环境。
在龙蜥社区，咱们应用 koji 来实现大量的构建，koji 是一个开源的 rpm 编译系统，源自 fedora，它应用 mock 来模仿构建环境，并可能将创立的编译工作主动调度调配到不同架构的机器，从而实现同源异构，koji 作为一个可能实现同源异构的编译构建零碎，在应用 rpm 作为软件资源管理的操作系统研发畛域，被大家宽泛应用，可靠性和稳定性也十分高。
这三个工具之间是层层蕴含的关系，如图 8，他们最终都是对 spec 文件进行解析和执行。
Spec 文件解析
图 9 spec 文件示例图
图 9 示例的 spec 文件就是 Rpm 包的灵魂，若要构建一个规范的 RPM 包，须要创立 .spec 文件，其中蕴含软件打包的全副信息。在 spec 文件中定义了很多重要的步骤、阶段，图 10 简要列出了 6 个要害阶段、及具体动作。
图 10 spec 文件中定义的次要阶段图示
图 11 rpmbuild 工具宏定义目录图示
咱们在编写 spec 文件时会有大量的宏定义，这些宏定义在在 rpm 构建过程中也十分重要，咱们倡议优先应用零碎定义好的、或者 rpm 工具所定义好的一些宏定义来编写 spec 文件，尤其是一些构建目录，图 11 就是罕用的一些目录所对应的宏定义示例。
以上就是龙蜥操作系统中软件包治理形式及构建办法的局部关键点。心愿能帮忙到对龙蜥社区感兴趣、并有志于退出国产开源操作系统开发工作的各位。当然，如果您是设计师、翻译、经营，龙蜥社区也能够成为大家施展拳脚的平台。
以下是对于龙蜥社区产品公布 SIG 组的指标及简略介绍：
制订、公布和保护龙蜥社区的打包标准、打包准则和依赖标准；
执行技术委员会的包引入和退出机制，预审软件包进入社区公布版本的申请，和经营 /QA 团队独特布局撑持社区版本的公布过程；
保护和治理 Anolis OS 公布中的软件包基线列表；
保护和治理 Anolis OS SIG 组软件包；
协调各 SIG 组的软件包划分、依赖抵触等;
Anolis OS 问题单解决和子各畛域 owner 协调调配。
退出产品公布 SIG 组
欢送更多开发者退出产品公布 SIG：
网址：https://openanolis.cn/sig/SIG…
邮件列表：os@lists.openanolis.cn
图片
敲重点啦
本次直播视频回放已上线至龙蜥社区官网（首页 - 反对 - 视频），直播 PPT 获取形式：关注龙蜥社区公众号，后盾回复【龙蜥课件】或【龙蜥视频回放】即可。
图 12 龙蜥社区官网截图
—— 完 ——
退出龙蜥社群
退出微信群：增加社区助理 - 龙蜥社区小龙（微信：openanolis_assis），备注【龙蜥】拉你入群；退出钉钉群：扫描下方钉钉群二维码。欢送开发者 / 用户退出龙蜥社区（OpenAnolis）交换，独特推动龙蜥社区的倒退，一起打造一个沉闷的、衰弱的开源操作系统生态！
对于龙蜥社区
龙蜥社区 (OpenAnolis) 是由企事业单位、高等院校、科研单位、非营利性组织、集体等依照被迫、平等、开源、合作的根底上组成的非盈利性开源社区。龙蜥社区成立于 2020 年 9 月，旨在构建一个开源、中立、凋谢的 Linux 上游发行版社区及翻新平台。
短期指标是开发龙蜥操作系统 (Anolis OS) 作为 CentOS 代替版，从新构建一个兼容国内 Linux 支流厂商发行版。中长期指标是摸索打造一个面向未来的操作系统，建设对立的开源操作系统生态，孵化翻新开源我的项目，凋敝开源生态。
龙蜥 OS 8.4 已公布，反对 x86_64、ARM64、LoongArch 架构，欠缺适配 Intel、飞腾、海光、兆芯、鲲鹏、龙芯等芯片，并提供全栈国密反对。
欢送下载：
https://openanolis.cn/download
退出咱们，一起打造面向未来的开源操作系统！
https://openanolis.cn
往期精彩举荐
1. 一款跑在云上的定制容器专属 OS 来了——LifseaOS | 龙蜥技术
2. 龙蜥社区 11 月经营亮点有哪些？月度大事件回顾来了
3. 摩尔线程正式退出龙蜥社区，国内开源生态再添芯力量
4. 直播回顾：如何凑合臭名远扬的 IO 夯？诊断利器来了 | 龙蜥技术
5. 网思科技退出龙蜥社区，共建开源操作系统生态