YaST 开发冲刺 27 亮点

又结束了三周的开发… 我们的常规报告开始了。来看看我们都做了些什么。

只读提案模块

本周，在 SUSECon 2016 期间，SUSE 宣布了一款令人兴奋的新产品。SUSE CASP – 一个基于 Kubernetes 的容器即服务平台。

这当然对安装程序有一些影响，例如某些产品（如 CASP）需要为某些子系统指定固定的配置。例如，已建立的软件包选择。在安装过程中不应允许用户更改这些固定配置。

我们实现了一种将安装提案中的某些模块标记为只读的可能性。这些只读模块随后无法从安装程序启动，因此它们的配置保持在默认初始状态。

在本冲刺中，我们已经在提案框架中实现了基本支持，未来我们可以改进相应的提案模块以更好地处理只读模式。

每个产品的 Btrfs 子卷处理

能够拥有只读提案并不是我们为使 SUSE CASP 成为可能而对 YaST 做的唯一改进。

当在安装过程中使用 Btrfs 时，YaST2 会提出一个要创建的子卷列表。不幸的是，该列表是硬编码的，并且对于每个 (open)SUSE 产品都是相同的… 直到现在。

从 yast2-storage 3.1.103.1 开始，可以在产品的控制文件中定义一个子卷列表，以及其他选项（请查看 SLES 和 openSUSE 示例以了解更多信息）。

<subvolumes config:type="list">
  <subvolume>
    <path>boot/grub2/i386-pc</path>
    <archs>i386,x86_64</archs>
  </subvolume>
  <subvolume>
    <path>home</path>
  </subvolume>
  <subvolume>
    <path>opt</path>
  </subvolume>
  <subvolume>
    <path>var/lib/libvirt/images</path>
    <copy_on_write config:type="boolean">false</copy_on_write>
  </subvolume>
</subvolumes>

此规范支持

禁用给定子卷的写时复制 (CoW)（默认情况下已启用）。
仅为一组架构启用子卷的创建。

改进的 AutoYaST Btrfs 子卷处理

AutoYaST Btrfs 子卷处理也得到了改进。使用与产品控制文件几乎相同的语法，您可以禁用给定子卷的 CoW 行为。

当然，如果您不需要此功能，则无需将您的配置文件调整为新的语法，因为它向后兼容。您也可以同时混合使用两者。

<subvolumes config:type="list">
  <subvolume>home</subvolume>
  <subvolume>
    <path>var/lib/libvirt/images</path>
    <copy_on_write config:type="boolean">false</copy_on_write>
  </subvolume>
</subvolumes>

另一方面，如果您正在运行 SLES，您会知道一个名为 @ 的子卷用作默认的 Btrfs 子卷。现在可以在配置文件的常规部分中关闭这种行为。

<general>
  <btrfs_set_subvolume_default_name config:type="boolean">false</btrfs_set_subvolume_default_name>
</general>

默认禁用安装程序自我更新

我们已经在本博客中多次讨论了安装程序的新自我更新功能。正如预期的那样，此功能将在 SLE-12-SP2 中首次亮相，但计划进行了一点小小的更改。为了确保 SLE-12-SP1 和 SP2 安装程序行为的一致性，自我更新功能将默认禁用。这没什么大不了的，因为启用它以获取最新的修复程序只需在初始安装屏幕中添加一个启动选项即可。

存储重构：yast2-bootloader 中的适配 EFI 提案

关于存储堆栈重构状态的上一份报告以以下悬念结束：“我们已经准备好所有制作可安装 ISO 的配料”。因此，正如预期的那样，我们在本冲刺中致力于将引导程序提案调整到新的存储层。如以下屏幕截图所示，我们成功了，并且安装程序现在已经可以提出一个有效的 grub2 设置来引导 EFI 系统。

这是否意味着用于新存储堆栈的测试 ISO 已经完全可安装？不幸的是，不是。为什么不是？原因实际上很有趣。

当前的分区提案仅适用于 MS-DOS 风格的分区表，因为我们希望首先解决最复杂的情况。另一方面，我们有意将引导程序提案的调整限制在 EFI 场景中。你知道吗？我们发现这种组合（MS-DOS 分区表 + EFI）目前在 Tumbleweed 中不起作用，因此在我们的基于 Tumbleweed 的测试 ISO 中也不起作用。

我们将在下一个冲刺中支持另一个场景。希望我们不会再次选择一个不受支持或损坏的场景。

让 libYUI 自由运行：首个可见步骤

如您所知，YaST 既有图形界面，也有文本界面。它们在相同的代码上运行，这归功于一个名为 LibYUI 的抽象层。最初它仅为 YaST 服务，但随着时间的推移，其他项目也开始使用它，特别是 Mageia 中的管理面板。此外，这些项目的开发人员开始为 LibYUI 贡献修复程序和改进… 比我们能够应对的更快。

最近，我们决定赋予 YaST 团队之外的人们在 LibYUI 项目中更多的权力。为了使之成为可能，同时确保它不会影响 YaST 的稳定性，我们一直在启用更多的持续集成测试。

作为改进协作的第一个成果，我们合并了 Mageia 的 Angelo Naselli 贡献的关于树形项目选择的修复程序。一旦我们完成持续集成设置（当然我们会随时向您通报），肯定会有更多的修复程序和改进。

YaST开发冲刺27亮点