openSUSE:构建服务概念 交叉开发/预包含
一些想法、经验和关于 obs 的建议，这些建议对于交叉构建和 kiwi 尤其重要。
摘要
目前，OBS 有一些用例，其中调用工作器/本地构建中的代码会被中断以执行特殊处理。这些代码本身不属于目标操作系统和架构，因此这些软件包不应位于目标仓库/架构中，也不应从目标仓库/架构中安装。
应用程序
Kiwi 在 obs 中
让我们从 kiwi-inside-obs 代码的最新更改开始。现在工作器使用 build 而不是主机系统。这很好，但有一些副作用：我基本上使用 Base:build、busybox 和一些其他库来构建一个迷你发行版。在更改之前，工作器使用主机的 kiwi，效果还可以。现在我没有所需的依赖项（kiwi、createrepo、python、sqlite、...）在我的小仓库中。它们必须位于“image”仓库中，并且“image”也需要从最顶层的仓库派生（如果仓库是派生/堆叠的）。由于 kiwi 在自己的 chroot 中执行镜像，因此 kiwi 包及其依赖项可以从 11.0 获取。这将使镜像即使对于没有 kiwi 本身的仓库也成为可能，或者使使用较新的 kiwi 变得非常容易。镜像本身不受此影响。
考虑到交叉 kiwi，这对于这种情况是强制性的，因为 kiwi-chroot 必须位于 $HOSTARCH 中。
作为结论，需要使 kiwi-chroot 独立于用于镜像的仓库。
使用 XEN 工作器进行交叉构建
现在考虑使用 XEN 工作器进行交叉构建：要在 XEN 工作器中使用 qemu-user-mode，需要一个最小的系统加上 $HOSTARCH 中的 qemu 来启动 XEN-VM。第一步是注册 qemu-binfmt-magic。所有其他软件包然后可以为 $TARGETARCH，因为用户模式处于活动状态。这意味着：预安装（和 Vminstall）加上 qemu 必须从 $HOSTARCH 获取，而不是从构建软件包的仓库/架构获取。这对 Martin 和 worker-api 来说是一个地方 ），但基本上与上述过程相同。
build/baselibs.conf
目前，baselibs 支持由 OBS 工作器或目标操作系统软件包中的特殊处理提供。可以删除这种特殊处理，并以与新的功能处理 qemu 预处理或 image/KWI 处理相同的方式进行处理。因此，不再需要直接从工作器主机操作系统/架构调用目标仓库/架构代码。
rpmlint
与 build/baselibs.conf 案例类似的是使用 rpmlint 检查器来检查构建结果。它像 build/baselibs.conf 一样有一个自己可选的配置文件。相似之处还在于首先安装一个额外的软件包 rpmlint。相似之处还在于在构建结果之后，执行一些操作。
测试框架
另一个与上述类似的应用是调用一个独立于软件包内部执行的测试的测试框架。这可以是更“静态”的分析，例如 rpmlint（实际上也检查编译消息），或者使用软件包执行的运行时测试（例如 ABI 测试、一致性测试）。
通用解决方案
如何将所有这些结合起来：为了将所有这些一步到位，我建议为 prjconf 创建一种机制，使用 2 个变量 - Preincludeproject 和 Preincluderepo。它们的作用是什么？
- Preincludeproject 应该设置获取 Preinstall 软件包（+Vminstall/qemu 或 +kiwi/qemu）的项目的项目。
- Preincluderepo 用于 kiwi 镜像，因为您可以在那里选择从哪个确切的仓库获取 kiwi chroot 包。对于交叉构建，可以省略此项，仓库将使用与原始项目中的名称相同的名称，以提供一致性。
这有一些副作用
- 调度器需要跟踪 Preincludeproject/repo 中的 Preinstall（+VM/+kiwi 如需）软件包，而不是原始项目。
- 工作器也需要从 Preincludeproject/repo 获取软件包
优势/用例
优势是
- 可以为 XEN 工作器实现交叉构建
- kiwi-inside-obs 镜像将独立于 .kiwi 文件中定义的仓库（如果手动调用，则如此）。“image”仓库可以为空 ！
- 可以在 OBS 内部实现交叉 Kiwi
结论
通过这些扩展，可以将当前的交叉编译代码从工作器中移除。所有步骤都可以在 prjconf 中配置，并通过包含仓库的专用软件包进行配置。因此，该过程对工作器是透明的。对于 kiwi，这使得镜像独立于 .kiwi 定义中使用的仓库。