YaST 开发冲刺 32 亮点

存储重构：无需 LVM 的加密方案

当前安装程序的一个已知限制是，只有在使用 LVM 时才能自动建议加密方案。出于历史原因，如果您想加密根分区和/或主分区，但不使用 LVM，则需要使用专家分区器……并希望引导加载程序建议正确。

但是新的存储堆栈（好吧，几乎是）将消除所有旧的限制。通过我们的测试 ISO，现在可以仅通过单击为基于分区和基于 LVM 的方案设置加密。正确创建了最佳的分区方案，并且一切都按照用户的期望进行加密。我们甚至在内部 openQA 实例中对其进行持续测试。

管理引导加载程序安装的部分尚未调整，这意味着生成的系统在能够启动之前需要手动修复 Grub……但这将在下一个冲刺（很可能是下一个冲刺）中完成。

改进 SLE12-SP1 的附加组件列表

SLES-12-SP1 中选择附加组件的对话框最初仅设计用于少量附加组件。不幸的是（或者幸运的是，取决于您的看法），附加组件的数量随着时间的推移而增长，并超过了文本模式 UI 的原始限制。

SLE-12-SP2 中的等效屏幕不受此问题影响，因为它使用具有可滚动列表的不同布局。但是 SP1 对话框看起来像这样。

如果您仔细查看屏幕截图，您会看到Web 和脚本模块在列表中丢失，并且底部的 返回、下一步 和 中止 按钮也未显示。

该修复程序减小了 详细信息 小部件的大小，并允许在每列中显示更多项目。现在甚至有足够的空间容纳另外三个附加组件。

此外，该对话框现在是动态的，并检查屏幕的当前大小。如果空间足够，则列表将以单列显示，以便标签不会被截断，并且 详细信息 小部件的大小将恢复到原始大小。

存储重构：Btrfs 子卷

子卷的管理是使 Btrfs 独一无二的功能之一，与更传统的的文件系统相比，需要特殊处理。事实上，这正是重写 libstorage 的几个原因之一——Btrfs 子卷从未完全符合旧的（当前的）libstorage 和 yast2-storage 的理念和数据结构。

在这个冲刺中，我们从头开始在 libstorage-ng 中引入了对子卷的支持，充分考虑了过去发现的所有特殊性、用例和场景。并且，希望以一种为未来做好准备的方式。

新功能已经工作并经过测试，并包含在最新版本的 libstorage-ng 中，但尚未在提案或 yast2-storage 的任何其他部分中使用。您需要等待另一个冲刺才能看到更明显的结果。至少如果“更明显”意味着屏幕截图。与此同时，如果您喜欢图像，可以随时欣赏 libstorage-ng 管理的内部结构生成的图形。

存储重构：系统升级

新的存储堆栈已经能够安装一个 openSUSE 系统很长时间了。虽然我们继续改进该领域，但下一个挑战是使用我们的测试 ISO 也能够从以前的 openSUSE 版本升级。

这意味着扫描硬盘查找以前的安装，允许用户选择一个，挂载相应的分区或 LVM 卷，执行每个软件包的更新，并执行一些最终任务，例如更新引导加载程序配置。

遵循 Scrum 鼓励的迭代方法，我们首先专注于前三个步骤，这是用户（或 openQA，无论如何）可以测试和验证的内容。因此，现在我们能够检测和列出预先存在的系统，并开始在选定的系统上进行升级过程。并且我们有自动化测试在 openQA 中以确保它适用于基于分区与基于 LVM 的布局以及基于 UUID 与基于名称的 fstab 文件之间的所有组合。

附加组件可以定义新的系统角色

YaST 在调整/修改安装工作流程方面具有很强的可定制性。除其他外，允许附加组件调整工作流程（添加/删除步骤）、定义新的提案等。现在，它们还可以定义新的系统角色。

让我们看一个添加新的邮件服务器角色的例子

<update>
  <system_roles>
    <insert_system_roles config:type="list">
      <insert_system_role>
        <system_roles config:type="list">
          <system_role>
            <id>mail_role</id>
            <software>
              <default_patterns>base Minimal mail_server</default_patterns>
            </software>
          </system_role>
        </system_roles>
      </insert_system_role>
    </insert_system_roles>
  </system_roles>
</update>

<!-- Don't forget to add the texts -->
<texts>
  <mail_role>
    <label>Mail Server</label>
  </mail_role>
  <mail_role_description>
    <label>• Software needed to set up a mail server
• No production ready yet!</label>
  </mail_role_description>
</texts>

现在让我们看看它是什么样子的

这让我们进入下一节…

角色列表在文本模式下变得响应式

YaST 的一个很好的特性是它能够在文本模式下运行，因此您无需图形界面即可安装或配置系统。因此，YaST 开发人员在处理用户界面时需要记住某些限制。

现在附加组件可以添加新的系统角色，我们注意到在对话框选择屏幕中存在一个潜在问题：如果添加了多个系统角色，我们最终将没有足够的空间。因此，我们决定改进系统角色的显示方式，使其适应 80x25 模式（即，只有 25 行文本）。让我们用一些例子看看这些变化。

这是屏幕在默认情况下看起来的样子，具有相当小的一组角色。

如果系统检测到没有足够的空间以这种方便的方式呈现所有信息，它将删除所有空格，以便至少所有信息都在那里，即使它看起来有点拥挤。

如果即使这样也不够，额外的描述将被省略，这为我们提供了更多的空间。

如果角色甚至在没有描述的情况下也无法适应，则将省略介绍性文本，这意味着我们可以在屏幕上呈现最多十八个（是的，18 个！）角色。

存储重构：引导设置模拟

如前几份报告中所述，我们正在与 SUSE UX 专家密切合作，以设计安装程序分区提案和专家分区器的改进界面。我们已经向您展示了我们用作讨论分区提案基础的文件，包括结论以及所谓的引导设置的第一个非常简单的原型。

在这个冲刺期间，这种协作工作集中在定义该向导的每个步骤应该如何工作和看起来。目标是获得一些界面模拟，作为即将到来的冲刺的起点。比以往任何时候都更重要的是，一张图片（好吧，四张图片）胜过千言万语。

防止在无法使用 Btrfs 快照时安装 CaaSP

CaaSP 是一个单一用途的系统，启用快照至关重要。因此，现在有一个检查机制，如果禁用了快照（例如，磁盘太小），它将阻止您继续安装。

存储重构：更好地处理 /etc/fstab 和 /etc/cryptab

对于新的存储堆栈，我们重构了处理 /etc/fstab 的类。虽然这通常不是值得过多描述的事情，但我们包含了对基于这个独立的 GitHub 项目的现有注释的智能处理。

这意味着文件开头和结尾的现有注释块将保持不变，并且任何内容条目之前的注释将保留在该条目上；也就是说，当该条目在文件中移动时（例如，由于挂载依赖关系），该注释将随其所属的条目一起移动。虽然这并非 100% 万无一失，但它比在重写文件时简单丢弃此类注释要好得多。

对 CaaSP 进行大量调整和错误修复

如您从以前的报告和其他来源中已经知道的那样，SUSE 的大量开发力量集中在构建即将推出的 CaaSP 上。作为该繁重开发过程的一部分，YaST 团队花费了冲刺的大部分时间来调整 YaST 以适应 CaaSP 并修复先前调整引入的错误。这是一系列难以在此处总结的更改，但它们有助于使 CaaSP 离最终目标更近一步。

继续前进！

我们已经计划了下一个冲刺，希望为新的存储堆栈、CaaSP 相关改进、AutoYaST 的一个惊喜以及更多内容带来更多功能。当然，它将伴随着相应的报告。

所以三周后见。敬请关注，玩得开心！

YaST 开发 Sprint 32 亮点