YaST 开发冲刺 23 亮点

我们修复了 40 多个错误，用了三周的时间！坏消息是，大多数错误修复不足以写一篇博文……但总有一些有趣的东西可以报道。

安装程序自动更新与 SCC 和 SMT 集成

安装程序自动更新功能现在与 SUSE 客户中心 (SCC) 和订阅管理工具 (SMT) 服务器集成。至今，获取安装程序更新仓库 URL 有三种不同的机制

用户定义（使用 SelfUpdate 启动选项）。
使用 AutoYaST 配置文件。
默认配置，在媒体中提供的 control.xml 中指定。

现在 YaST2 能够向 SCC/SMT 服务器请求仓库 URL。 URL 的确定方式的细节记录在仓库中。

修复了带有超时功能的对话框中的错误并增强了可用性

如您所知，可以使用 AutoYaST 以自动甚至完全无人值守的方式安装 (open)SUSE。 AutoYaST 可以配置为向用户显示自定义配置对话框，并在自动选择默认选项之前等待一定时间。至今，用户停止倒计时的方式只能是开始编辑对话框中的某些字段。

我们收到一个错误报告，因为该功能在某些情况下无法按预期工作，因此，除了修复问题之外，我们还决定稍微改进用户界面以提高可用性。现在，更多用户交互被考虑在内以停止计数器，特别是我们添加了一个新的“停止”按钮，显示剩余秒数。您可以在下面看到结果示例。

此外，一如既往地遵循“童子军规则”，我们还利用这个机会添加了自动化测试，以使 YaST 的这部分在未来更加健壮。

在安装过程中自动集成附加仓库

有时您希望通过添加几个额外的软件包或提供与媒体一起的固定软件包来扩展常规安装介质。

为此，安装程序可以自动注册一个附加仓库。您所要做的就是将仓库放在安装介质上，并添加一个文件 /add_on_products.xml，该文件指向此仓库。

文件如下所示

<?xml version="1.0"?>
<add_on_products xmlns="http://www.suse.com/1.0/yast2ns"
    xmlns:config="http://www.suse.com/1.0/configns">
    <product_items config:type="list">
        <product_item>
            <name>My Add-on</name>
            <url>relurl://myaddon?alias=MyAddon</url>
            <priority config:type="integer">70</priority>
            <ask_user config:type="boolean">false</ask_user>
            <selected config:type="boolean">true</selected>
            <check_name config:type="boolean">false</check_name>
        </product_item>
    </product_items>
</add_on_products>

您可以定义以下元素

<name> 是您的仓库名称
<url> 指向仓库位置；您可能希望在此处使用 relurl 方案，该方案给出相对于主安装仓库的位置
<priority> 是仓库优先级（较小的数字表示较高的优先级，主安装仓库的优先级为 99）
<ask_user>：是否应该询问用户是否添加仓库？
<selected>：是否应该自动选择仓库？
<check_name>：是否应该将仓库的实际名称与 <name> 元素的值进行匹配？

您可以在此文件中列出多个仓库。

如果您太懒记不住所有这些，mksusecd 可以为您完成所有这些操作。

例如，如果您有一组想要使用的新内核软件包，请执行

mksusecd --create new.iso --addon kernel-*.rpm --addon-name 'my kernel' sles12-sp2.iso

这将基于 sles12-sp2.iso 创建一个新的 iso，它将安装您的新内核软件包。

存储重构：代码的小步，持续集成的大飞跃

在清除错误的过程中，我们设法抽出一些时间来继续存储堆栈重构……缓慢而稳定。 storage-ng OBS 仓库中的定制 Tumbleweed 镜像已经能够分析大多数系统，创建系统存储设备的内存表示，这将用于操作磁盘并提出分区方案。不幸的是，这种表示仅可见于 YaST 日志中，因为修复安装程序错误比在 UI 中表示该信息更紧迫。

这变成了一个重要的里程碑，不是因为功能本身或代码的价值（我们只是添加了几行 Ruby 代码），而是因为第一次，某些软件包中的依赖项从 libstorage 切换到 libstorage-ng。这对代码组织和我们的持续集成基础设施，特别是 Travis CI 集成，产生了重要的影响，这涉及到 .deb 包的生成。现在我们可以说，我们的持续交付工作流程（从 Github 到 OBS，经过 Jenkins、Travis、Coveralls 和 Code Climate）没有任何旧存储代码的痕迹。

此外，我们还在新库中的 LVM 支持方面取得了良好的进展，能够识别和操作内存中的各种 LVM 结构。

开放的乐趣：更新 SUSE Linux Enterprise 文档

我们工作的重要组成部分，特别是在新版本发布日期临近时，是帮助塑造 SUSE Linux Enterprise (SLE) 文档。 SUSE 产品的最强劲之处之一是出色的 SUSE 文档团队，他们像公司中的其他所有人一样，拥有开源基因。提出改进和更新文档的建议就像在完全开放的 Github 文档仓库中创建拉取请求一样简单……而且任何人都可以做到！

文档团队使用 Docbook，但他们会接受其他格式（例如 Markdown）的贡献，并将其自己转换为 Docbook……仅仅因为他们是如此酷。

更好地支持使用 EFI 的 ARM 系统

世界充满了很酷的 ARM64 设备，SUSE 和 openSUSE 都在积极努力支持尽可能多的设备。在本次冲刺期间，我们采取了另一小步，改进了使用 EFI 的 ARM 系统的安装程序分区建议。

这并不是全部，伙计们

正如我们一直说的，这只是我们认为足够令人兴奋以包含在我们开发报告中的工作的一小部分，因为我们不想用每个已修复错误的细节来烦扰您。在此安装程序错误修复阶段，这一点比以往任何时候都更真实，下一个冲刺的计划也与此类似。然而，在下一个报告中，我们预计将有一些关于安装程序自动更新功能和新存储堆栈中 LVM 支持的有趣消息。请继续关注。

YaST开发冲刺23亮点