显示非常长的变更日志
我们收到了一份错误报告，指出当软件包管理器中显示非常长的软件包变更日志时，YaST 无法响应。事实证明，某些软件包具有巨大的变更日志历史记录，包含数千条条目（例如 kernel-default 软件包几乎有 5000 条）。这会产生一个非常长的表格，需要很长时间才能解析并在 UI 中显示。
解决方案是限制 UI 中显示的条目最大数量。无论如何，对于如此长的文本，你很难轻松阅读，你需要一些搜索功能，而 YaST UI 并没有提供该功能。
找到这个限制，那个神奇的数字，并不容易，因为我们希望保持向后兼容并显示尽可能多的条目，但仍然避免出现具有巨大列表的病态情况。
最终，我们决定将限制设置为 512 条变更条目。绝大多数软件包的条目远少于此，因此你可能不会注意到此剪切功能。当达到限制时，将显示一条显示完整日志的命令，以便在需要时轻松查看缺失的部分。（提示：该小部件支持通常的复制&粘贴功能，你可以使用 Ctrl+C 复制显示的命令，并直接将其粘贴到终端窗口中。）
存储重构：重写分区程序中的 MD RAID 支持
在上一份报告中，我们告诉大家我们正在重写 YaST 分区程序，以使用新的存储堆栈和现代可重用的 CWM 小部件，同时在表面上保留完全相同的行为和外观。我们一次实现一项功能，而这次轮到 MD RAID。
现在，分区程序会显示当前的 RAID，并显示有关它们的详细信息以及用于构建每个 RAID 的设备。如果一张图片胜过千言万语，那么这里有 3000 个字。
不，你不能为 CaaSP 单独划分 /var/lib/docker 分区——给你看
我们全新的面向容器的解决方案 SUSE CaaSP 及其 openSUSE 对应版本 Kubic，需要将 /var/lib/docker 作为单独的分区，原因有很多。它已经是一个 Btrfs 子卷，但这还不够独立。 
问题在于旧 YaST 存储子系统中的自动化存储建议无法处理类似情况；它可以处理根目录、交换分区和可选的单独 home 分区（如果使用 LVM 的话）。仅此而已。不幸的是，扩展 control.xml 文件的当前语法以指定任意分区并调整旧建议的代码以理解和处理此新规范几乎是不可能的。可悲的是，我们必须承认旧代码如今很难维护，并且不够灵活，无法以安全的方式适应这种变化。
这是我们目前正在重写整个 YaST 存储子系统的一个原因（众多原因之一），正如你从这篇博文中许多之前的文章中已经知道的那样。但是，正如你所知，新的系统将与 SLES15 和 openSUSE Leap 15.0 一起首次亮相，对于当前的 SUSE CaaSP 和 openSUSE Kubic 来说太晚了。
我们决定引入一个基于旧建议的补丁，深知在代码中积累的补丁会像 Dust Puppy 一样发展自己的生命。但我们计划在 StorageNG 到达后立即杀死该补丁。
因此，该补丁只是使用单独 home 分区的逻辑并对其进行重新利用，保留 control.xml 中的所有相应参数，并引入另一个名为 home_path 的参数，可以在其中指定该分区的实际挂载点——在本例中为 /var/lib/docker。权衡是不能同时存在单独的 /home 分区。
该“功能”不应在 CaaSP 的特定用例之外使用，我们甚至考虑过不要公开记录它，以避免滥用。但我们秉持开源精神，无论做什么，都公开进行。即使是（相当令人尴尬的）事实是我们认为对我们代码的某些部分进行更改过于冒险。但再次强调，这就是我们大力推进存储层重构（Storage-NG）的原因：我们希望重新控制该部分。
存储重构：使用 AutoYaST 的自定义分区
说到新的存储层和我们之前的文章，你已经知道我们正在努力将其与 AutoYaST 集成。目前，支持自定义分区布局，但仅使用纯分区和 LVM。其他功能，如 RAID 或 Btrfs 子卷支持，仍然缺失。
新代码的一个优点是它尽可能地依赖于新的存储层。在旧版本中，AutoYaST 实现了它自己的逻辑，这导致了一些意想不到的问题。幸运的是，不再存在这种情况，而且新代码看起来更容易扩展和维护。
YaST 不再直接写入 /etc/vconsole.conf
在配置系统键盘时，YaST 曾经直接将键盘映射配置写入 /etc/vconsole.conf 文件。但是，这种方法不再合适，因为它可能会对其他工具造成不良影响。现在，YaST 使用 Systemd 工具 localectl 来设置 /etc/vconsole.conf 中的键盘映射，而不是直接写入它。这是 YaST 成为 Systemd 世界中一个好公民的又一步。
存储重构：命名的 RAID 阵列
如果你使用 MD RAID 阵列，你可能知道有两种方法来识别它们——按编号或分配有意义的名称。命名的阵列使用设备名称，如 /dev/md/<name>，而不是 /dev/md<number>。
在此冲刺期间，我们教会了新的 libstorage 如何创建和管理命名的 RAID 阵列，除了已经支持的编号阵列之外。如果用户决定这样做，MD RAID 名称将用于 fstab，而不是 UUID（这是旧 libstorage 的唯一选项）。我们还确保在多种情况下改进行为，因此我们认为旧存储中的一些错误已通过 storage-ng 得到修复（或者如果你更喜欢，则已过时）。
Linux 还支持 /dev/md_<name> 形式的名称。新的库也能够处理这种格式，但该功能被故意禁用并记录为不受支持，因为无法 100% 验证系统的其他部分在这种情况下是否能正常工作。我们非常重视质量保证，然后再将一项功能标记为“受支持”。
如果你对显示分区程序中 RAID 支持的屏幕截图不够满意，这里有更多图片。但是，像在库中实现的东西一样，“图片”并不意味着屏幕截图，而是漂亮的自动生成的图表。
敬请期待
当然，在过去的两个星期里，我们还做了很多其他事情，尽管其中一些被认为对本报告不感兴趣或未按时完成。我们已经在努力完成未完成的工作并实施新的令人兴奋的改进。好消息是，你只需要等待两个星期才能了解更多信息……敬请期待。