Fedora koji构建系统详细教程之二 -- 构建

本文主要是介绍Fedora koji构建系统详细教程之二 -- 构建，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

写在前面

本篇文章是上一篇文章的继续，由于koji里面的内容实在是太多，都塞进一篇文章里会显得很臃肿，于是我就拆成了两部分。在上一篇文章里，我们已经部署好了Fedora koji系统，此时kojihub已经运行、可以通过kojiweb或koji命令去访问，并且也打开了kojira和kojid,这时候你已经具备构建的能力了。在这篇文章里，我会在x86_64上构建x86_64的rpm包，然后再进行RISC-V rpm包的构建，因为这涉及到一个RISC-V虚拟机部署问题，实际上内容和问题也不少。这篇文章仍然需要慢慢完成，内容也比较多，请大家仔细观看。

一、构建前准备

1、创建标签并配置

koji里的标签称为tag，这个tag就是某一个Linux发行版的所有软件包的集合的名称。比如说我要创建一个f40_x86_64这个标签，意思就是说这个标签代表了Fedora40 x86_64这个发行版它所规定的所有软件包集合的名称叫做f40_x86_64.实际上这个名字你是可以随便取的，不过最好是取得要规范。名称只是一个象征，真正重要的是你导入的软件包名和版本信息，它们会和你所创建的这个标签绑定。不仅仅是Fedora可以这样，比如说openEuler你也可以这样，只要你获得了或者自己制作了这个软件包信息的txt文件，就可以创建一个名叫openEuler24.03_x86_64这样一个标签去代表这么一个24.03openEuler的发行版。

甚至于说比如我喜欢LFS，那么我就可以自己制作一个属于自己的Linux发行版。我举个例子，比如我想基于LFS制作一个April Linux发行版，那么我就可以自己弄一个april_pkg_list.txt，然后创建April_x86_64标签，这么构建出来的一套软件包再发行出去。那么我的这个April Linux操作系统就可以发布出去让大家都使用了！

我以iscas的kojiweb展示出来的信息为例，就是说每一个Linux发行版对应一个tag，你每需要一个仓库就得来一个标签。同一发行版如果版本不同，也需要独自创建一个tag.

不知道大家对这个标签tag的概念是否已经清楚，标签代表着某个release（或者基于这个release的变体/开发版本）所包含的所有软件包集合。

koji add-tag f40_x86_64# koji add-tag 标签名      增
# koji remove-tag 标签名   删
# koji list-tags          查

添加（package）软件包列表（只是包名）到这个tag:

cat f40_pkg_list.txt | xargs -n 1024 koji add-pkg --owner kojiadmin f40_x86_64

大家还记得f40_pkg_list.txt吧，这个就是在第一篇文章里从Fedora project的kojihub里获取到的信息，因为那时候april_zhao用户的koji命令默认指向Fedora官方的koji ，所以获取到这个文件是比较容易的。但是你一旦部署好了之后，让其指向你自己部署的kojihub，那么这个文件你就获取不到了，所以我把这部分放在第一篇的最前面。但是如果说你当时没有通过Fedora的kojihub获取到这个文件也没有关系，你可以（待写）。

批量导入包名到标签里。在导入的过程中可能出现database outage的问题，因为postgresql会莫名其妙不太稳定，所以你可以重启一下数据库然后重新执行导入包名的命令。

sudo systemctl restart postgresql koji-sweep-db

一旦你导入了这些包名，那么你的Summary统计信息就不会像以前那样光秃秃的了，而是会把这些信息展示在这里，你可以对比一下Fedora和iscas的kojiweb是不是也是这样。

这里大家可以对比观察现象，就是说你每做一步操作，就去kojiweb里看看有什么地方不一样。眼见为实，你实践过了，就不会觉得这些概念很抽象了。

2、导入组信息

1) fedora功能分组信息

koji import-comps fedora_comps/comps_f40.xml f40_x86_64_build

comps_f40.xml 文件定义了软件包组的列表和描述，这些组可能包括特定的应用程序、工具和库。通过导入这些信息，可以帮助在构建过程中正确选择和安装需要的软件包组，确保构建环境的完整性和一致性。

2) 导入koji编译系统特定的分组信息

koji import-comps comps_f40_koji.xml f40_x86_64_build

comps_f40_koji.xml在第一篇文章里也已经得到了。

comps_f40_koji.xml 文件定义了一系列与构建和打包相关的软件包组，例如 appliance-build、build、kiwi-build、livecd-build、livemedia-build 和 srpm-build。这些组包含了一些必需的工具和库，用于特定类型的构建任务，如构建 SRPM 包等。

3、创建构建目标

koji add-target f40_x86_64_build_target f40_x86_64_build f40_x86_64# koji add-target <target name> <build tag> <des tag>   添加构建目标
# koji remove-target <target name>                      删除构建目标
# koji list-targets List the build targets              列出构建目标

构建目标（build target），描述的是一个构建的过程，其中包含你已经创建的前两个标签：tag和build tag。

4、createrepo权限与重建仓库信息

我们现在需要重建仓库，但是host默认的defaut权限是无法进行这个操作的，需要createrepo权限才可以，所以我们需要给我们唯一的host（kojibuilder1）添加这一权限。

koji add-host-to-channel kojibuilder1 createrepo# koji add-host-to-channel host名 channel权限名
# koji remove-host-from-channel host名 channel权限名

可以在命令行如此操作，也可以在kojiweb里点击添加。

koji regen-repo f40_x86_64_build

这也是我们首次提交任务，当你执行这行代码之后，就会在Tasks界面里提交两个任务。

由于我第一次提交任务之前忘记给予kojibuilder1 createrepo权限了，所以我手动把任务1和任务2取消并重新创建。

如图所示，现在kojihub已经自动安排我们的kojibuilder1也就是本机上的kojid进行工作了，因为此时Load负载不为0,并且这个任务本身不难，所以没有把4.0的总负载给占满。

运行一段时间之后，regen-repo成功，我建议的话是这个regen-repo操作就让有权限访问/mnt/koji（这个可以由你来设置）的机器来完成就好。因为它涉及到一个文件系统的访问，如果让其他设备上的kojid来运行可能会没有足够的访问权限、导致regen-repo失败。也就是说regen这些操作由“本机”来做，让对这个目录有读写权限的那台机器来做，给予那台机器对应的kojibuilder这个createrepo权限，这样是最稳妥的。