生命中的一天 Fedora 打包机

有没有想过参与其中是什么感觉 Fedora 项目？ 有许多不同的角色和类型的人可以帮助 Fedora 这是什么。 一种常见的贡献形式是 包装. 这是当有人拿到软件时，将其“打包”在 RPM 格式，并将 RPM 发布到 Fedora 存储库。 成为打包者的过程中有一些步骤。 在本文中， Fedora 打包机 詹姆斯·霍加斯， 负责 ownCloud, 证书机器人 （以前称为 LetsEncrypt）等等，详细介绍了生活中的一天 Fedora 打包机。

包装在 Fedora

我经常被问到打包者扮演什么角色，以及为什么上游版本需要这么长时间才能显示为一个包 Fedora 或EPEL。 它不只是从一些 FOSS 项目中获取现有的 tarball 并从中制作 RPM 吗？ 在本文中，我们将逐步介绍 ownCloud 更新中发生的事情以及到达的过程 Fedora 和EPEL。

上游监控

Fedora 用途 阿尼提亚 跟踪上游版本。 您可以在以下位置找到 Anitya 的实际应用 release-monitoring.org. 在撰写本文时， Fedora 监控 跟踪超过 10,000 个包裹。

当 Anitya 在上游检测到新版本时，会在 Bugzilla 上记录一个错误，以提醒维护者有新版本需要检查。 这是我们旅程的开始。

第一步

特别是在ownCloud的情况下， 作曲家 用于跟踪 PHP 依赖项。 新旧对比

作曲家.json

files 可以快速初步检查我们应该注意的任何 PHP 依赖项更改。

其他项目将有不同的方式来提供依赖要求，即使它只是一个 README 文件。

如果这是一个小更新，几乎没有或没有第三方更改可能会影响捆绑，我们有最简单的方法可以遵循。 一个快速版本的碰撞 规格文件 一个测试版本就足够了。

$ rpmdev-bumpspec -n 9.0.3 -c "new release 9.0.3 upstream" owncloud.spec
$ spectool -g owncloud.spec
$ fedpkg srpm
$ mock -r fedora-rawhide-x86_64 ./owncloud-9.0.3-1.src.rpm

如果变化很小（所以补丁仍然适用），这很有可能会起作用并且

嘲笑

将成功构建包。 如果是这样，那么测试构建将是下一个活动。

在路上颠簸

如果有足够的更改导致现有补丁不再完全适用，这将导致构建失败。

嘲笑

只能运行 rpmbuild 的给定阶段。 在这种情况下，我们感兴趣的是

%准备

阶段，因为补丁需要更新。 从这里我们可以看到补丁是如何失败的以及需要更新的内容：

$ mock -r fedora-rawhide-x86_64 --short-circuit=prep ./owncloud-9.0.3-1.src.rpm
$ cd /var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/owncloud

一般来说，我从这里找到的最快路线是创建一个临时 git repo，应用补丁或手动进行更改，然后

混帐差异

生成将应用干净的新补丁。

将它们带回原始规范并生成新的 SRPM 让我们很快回到正轨。 一旦模拟构建成功，我们就可以测试构建。

遭遇“道路工作”

在 Fedora （以及 EPEL），我们有强烈的偏好 解绑 在可能的情况。 捆绑是当您在包中包含其他软件依赖项时。 一个 example 可能是一个 Web 服务器，它与它“捆绑”在一个 OpenSSL 版本中，以处理 HTTPS。 直到最近，捆绑还需要一个特定的 Unbundling Exception 从 Fedora 包装委员会 如果有原因无法进行拆分。

即使取消了严格的要求，仍然首选解绑。 如果依赖项发生安全问题（想想 心脏出血 使用 OpenSSL），所有使用它的应用程序都会自动获取更新，而不是需要自己更新的应用程序。 它还确保使用特定库的应用程序之间的行为一致。

当比较

作曲家.json

对于 PHP 包，它揭示了依赖项要求的变化。 大多数情况下，这是由于错误修复或安全问题导致的版本升级。 我们需要检查的第一件事是已经存在的 Fedora 和/或 EPEL。 由于我们上面概述的发布监控，很可能已经打包了更新版本的库。 但是，有时包裹会落后。 这可能是由于多种原因，维护者缺乏时间或由于某种原因未能构建新版本。

如果更新的依赖项尚未满足，则 布吉拉 和 数据库 需要检查以查看是否正在进行更新。 如果没有，则需要记录错误以联系其他维护者。 如果他们遇到问题，可以帮助他们。

偶尔，有人注意到一个包裹掉在了路边。 毕竟，我们是志愿者。 有时，生活变得忙碌，进行维护的能力受到影响。 在这种情况下，我们有 一个特定的过程 允许 Fedora 工程指导委员会，FESCo，将包裹传递给对其感兴趣的其他人。

一旦更新了新的依赖项，就可以将其添加到构建环境中！ 我们完成了道路工作，并回到了补丁的道路上，就像“路上的颠簸”。

寻找天坑

最大的延迟来自主要版本更新。 这些几乎总是涉及变基补丁，或者可能删除它们。 如果上游合并或修复补丁处理的问题，就会发生这种情况。 它不仅可以包含新版本的库，还可以包含最近包含的库。

如果依赖项有重大更新，则可能需要与其他维护人员进行一些联络和沟通。 您将需要查看更新可能会影响什么，然后与他们合作以符合每个人的最大利益。 这可能意味着在更新另一个包以与新库版本兼容时，暂时保留您自己的包。

如果需要一个以前不存在的新库，那么这可能涉及一个新包 Fedora 如果它还不存在。 这将需要一个 包裹审查. 对于一个新的包裹，可能需要一些时间才能通过，这取决于包裹对其他人的兴趣 Fedora 社区中的包装商。

一旦任何新包通过审查，就会出现在 Fedora 存储库，并更新任何现有的依赖项，我们终于可以进行有效的构建并执行测试。

测试构建

根据包的复杂性，测试所需的时间和精力会有所不同。

在某些包的情况下（例如

证书机器人

，正式称为

让我们加密

， 或者

sslh

) 有一个测试套件作为

％查看

在构建中。 在 Amazon Web Services EC2 实例或个人服务器上进行测试以验证行为相对简单。

在 ownCloud 的情况下，需要进行更多的测试。 这是由于涉及的各种形式的组件，作为升级进行测试，以及作为全新安装进行测试。

上游有测试套件，但它们不在发布 tarball 中。 我还没有时间调查它们是否可以纳入 rpm 规范

％查看

. 我们所做的

％查看

在规范中是如果有任何新的捆绑库（而不是只是碰撞版本），我们可以自动正确加载所有 PHP 库。

推送到存储库之前的大部分测试是手动的。 在撰写本文时，我目前对即将推出的 ownCloud 9.0.2 软件包的测试矩阵包括：

我在做我不会为之建造的假设 Fedora 22，基于各种位的预期时序。 8.2 更新已在 Fedora 22 也一样。

自动化测试

我相信您可以想象手动安装这些环境中的每一个以进行测试是多么的负担。 这是使用的地方 配置管理技术 如 Ansible 反对 虚拟机 客人上场。

善用 虚拟安装工具, 编写虚拟机 (VM) 的生成脚本以进行测试很简单。 随着 BTRFS reflink 复制，这几乎是即时的并且占用很少的磁盘空间。

接下来是 Ansible 剧本。 这利用了动态 Ansible 库存 用于查找正在运行的 VM 并为其分配角色的 Python 脚本。 Web 服务器和数据库选择基于来宾自动所在的 Ansible 组。 为了在建筑物之间轻松切换， Fedora 存储库和本地

嘲笑

构建时，我可以设置变量以启用测试存储库和本地存储库。

创建新的 ownCloud 包的全新安装以进行测试变得像运行 Ansible playbook 一样简单。

$ ./gen_oc_vms.sh
# wait for VMs to be accessible, this can be tested by checking ./libvirt_inv.py --list
ansible-playbook -i ./libvirt_inv.py -e "localrepo=true testingrepo=true" site.yml
# wait for playbook to complete
$ ./libvirt_inv.py --list | json_reformat  | awk -F':' '$1 ~ /ansible_host/ {print $2}' | sed 's/[", ]//g' | while read ocip; do xdg-open "https://${ocip}/owncloud/"; done

此时，我们将打开每个安装的 Web 界面，并且可以登录并检查每个安装的功能。 这可能包括 SMB 外部存储或对 ownCloud AppStore 的访问。 如果成功，下一步是测试升级：

$ ./kill_oc_vms.sh
$ ./gen_oc_vms.sh
# wait for VMs to be accessible, this can be tested by checking ./libvirt_inv.py --list then install current OwnCloud
ansible-playbook -i ./libvirt_inv.py site.yml
# wait for playbook to complete
$ ./libvirt_inv.py --list | json_reformat  | awk -F':' '$1 ~ /ansible_host/ {print $2}' | sed 's/[", ]//g' | while read ocip; do xdg-open "https://${ocip}/owncloud/"; done
# Do some basic configuration such as install some apps and verify basic access is good
$ ansible-playbook -i ./libvirt_inv.py -e "localrepo=true testingrepo=true" site.yml
# Verify the "owncloud needs to be upgraded" page is shown, carry out the upgrade and verify it worked correctly and apps can be re-enabled etc

发布更新

一旦所有这些都完成并且我们对构建感到满意，对规范文件的更改将被推送到 Fedora git仓库. 这 Fedora 构建系统， 小曲仅在为官方构建时从这个受信任的位置构建 Fedora 回购。 构建后，将在 菩提. Bodhi 用于管理构建的包进入测试存储库，然后在一周或足够的积极 karma 测试后，进入稳定存储库。

完整的打包体验

如您所见，从最初的上游版本到官方稳定版有时可能是一个复杂的过程 Fedora 存储库。 我们尽最大努力确保构建一个经过良好测试的包，甚至在它到达 Rawhide 和测试存储库之前。

我希望这能为我们的活动提供一些见解 Fedora 作为打包者以及为什么有时需要更长的时间才能看到该更新在

dnf更新

有时可能超出预期或希望的列表。