openSUSE:ALP/Workgroups/GrassyKnoll
从技术角度来看，总结该项目的最简单方法是创建一个非常缓慢的滚动 Tumbleweed，以至于一旦 ALP 发布，Grassy Knoll 将在 3 或 6 个月后进行一次更新，纳入新的软件包。我们需要更多关于 ALP 组件生命周期的细节才能确认这一点，但 6 个月会更理想。
- 不使用事务更新
- 不使用容器在操作系统的核心中，但将支持运行来自 ALP 的容器化工作负载
- 成为一个易于社区构建的基础。
- 支持 X11 桌面环境
- 成为嵌入式系统的理想解决方案。
- 从 Leap 15 系统迁移
- 尽可能继续提供 rpm 格式的桌面应用程序。
范围
- SUSE ALP 支持的“Bare Metal Mode”中的软件包
- KVM 服务器
- X11
- Enlightenment
- XFCE
- GNOME
- 任何其他人想要贡献的内容。
- x86_64
- aarch64 (Raspberry Pi)
这个范围的原因是这些是我个人 KVM 桌面服务器的要求，以及 XFCE 作为流行的社区选项。这应该足以作为许多其他社区软件包的基础，即使我勉强能保证维护。想法是随着人们的加入提供帮助，我们会添加更多。
Hackweek 2023 期间实现的目标
- 为“社区软件包”设置“Backports”仓库
- 基于 ALP 创建了一个基本的通用 kvm 镜像
- 为 Enlightenment、GNOME 和 Xfce 创建了桌面 KVM (qcow2) 镜像
- 为 Enlightenment、GNOME 和 Xfce 创建了桌面 Live CD (iso) 镜像
待办事项
- 基于现有的 tumbleweed 测试设置了基本的 openQA 测试。
- 创建一个 Raspberry Pi 镜像进行测试
- KDE 镜像
设计
基本概念是遵循我们对 Leap 所做的事情，创建一个包含来自 Tumbleweed 的社区软件包的“Backports”仓库来填补空白。这里的一个区别是 SUSE 的 SLE 仓库包含大约 10,000 个软件包，而 ALP 包含大约 2,000 个软件包，尽管如此，我们只需要添加大约 350 个软件包才能达到我们的初始目标。这包括 yast 和许多 gnome 构建依赖项，我们希望一旦它们可用，能够从 ALP 源代码中获取。但即使这个数量对于一个小团队来说也是可管理的，尤其是在软件包存在于 Tumbleweed 中的时候。
一旦我们有了所需的软件包，我们就可以使用现有的工具（例如 kiwi）来创建用于测试的镜像，包括 livecds。SUSE 的 Factory first 策略的最大好处是，只要拥有正确的软件包，在 Tumbleweed 中有效运行的一切也在这里有效运行。希望一旦我们知道 SUSE 计划如何构建他们的容器镜像，我们也可以使用相同的方法，并结合 backports 仓库来构建 openSUSE 社区镜像，如果人们有兴趣维护它们。不过，我们本着这个 hackweek 没有进行调查。
Lubos 还花费了 hackweek 的大部分时间与 d-installer 合作，以查看它是否目前适用于我们需要的额外功能。
设计限制
虽然可以通过简单地以不同的方式构建镜像来规避 ALP 的许多限制，但由于 ALP 二进制文件是在没有某些功能（例如 AppArmor 和 NIS）的情况下构建的，因此很难避免其他一些设计决策。
结果
首先，我们有一个包含到目前为止我们所需的所有额外软件包的 backports 仓库，我们还有一个 wiki 页面记录了为什么需要这些软件包，您可以从这个 wiki 链接找到它们。其次，我们构建了几个可供下载和测试的 KVM 镜像，包括 Xfce、Enlightenment 和一个通用的控制台环境。这些镜像非常有限 - 实际上只是一个概念验证，因此除了非常基本的可用性和基本的桌面选项外，不要期望太多。第三，我们构建了 live cds 也用于测试和可供下载。最初，我们致力于 Xfce 和 Enlightenment，因为我个人的兴趣，但就在那时 Valentin 发现我们离一个可用的 Gnome 系统只有大约 30 个软件包，并决定尝试一下。但是，Gnome 的未来外观将取决于 SUSE 如何为其 ALP 产品处理它。我们还有一个 D-Installer 镜像可用，作为安装的证明。同样，您应该可以在此页面上找到这些链接。
未解答的问题
- 桌面应用程序 - SUSE 的 ALP 可能会使用 Flatpaks，如果这些是在 OBS 上构建的，则可能可以从相同的源代码构建 rpm 版本。也有可能一些 openSUSE 贡献者更喜欢将他们的应用程序作为 rpm 格式发布。所以理想情况下，我们希望同时支持两者。
- 维护/发布计划 - 理想情况下，在一年中的计划时间，我们将把 SUSE 的 ALP 和社区的更改捆绑到某种形式的点发布中。例如，SUSE 可能会在 python3.10 堆栈仍然受支持时发布 python3.11 堆栈，因此最好选择一个点来定期迁移，而不是在随机时间发生迁移。目前，我们在这方面仍然没有足够的细节来真正评估什么可行。
- SUSE 可能会使用比过去更少的仓库，我们可能需要向 zypper / yast 添加基于仓库的过滤，以便它们只显示仍然受支持的软件包进行安装。但同样，我们仍然在等待更多细节。
接下来
我们现在知道这个概念 A 有效并且 B 可以维护，所以如果社区对这个概念有广泛的兴趣，下一步可能是在 Leap 15.5 发布后，创建一个类似于 Leap 仓库的 backports 软件包仓库，并使用机器人等。然后让维护者贡献他们希望维护的任何其他软件包。同时，设置镜像构建和 openqa 测试。与此同时，我命名空间下的 backports 仓库中的软件包大多链接到 Factory（我会修复其余的），所以我将密切关注它们并检查它们是否保持构建。如果您维护一个软件包并且对依赖项列表感兴趣，您还需要维护才能使其工作，请告诉我，我可以将其从 Factory 链接过来。但是，请注意，perl、python 和 ruby 语言堆栈等的大部分内容尚未打包。此外，为了追求更轻量级的桌面，我想打包 sway，因为它将很好地表明其他较小的 wayland 桌面需要什么。
名称是另一个需要考虑的问题，我们是否应该只使用 Leap 来表示 SUSE ALP 产品的开源构建，或者我们应该做一些完全不同的事情？鉴于 SUSE 正在使用阿尔卑斯山的名字作为发布代码名，我选择做一些类似但不同的事情。这个项目应该比攀登阿尔卑斯山更极端，更像是在山丘上进行轻松的野餐或散步，所以这个原型机的代码名是 Grassy Knoll，因为它听起来很酷，也许我玩得太多 dwarf fortress 了。无论如何，这可能不是该项目长期的最佳名称。
常见问题解答
- 为什么我们没有研究 KDE？ - KDE 具有更大的软件包集。此外，我的初始目标之一是创建一个足够小的东西，如果我需要用几个人主要用于我们自己的用例来维护它，我们就能做到。KDE 不符合这个范围，但是从我们本周的测试来看，如果有人想维护 KDE，它不应该需要对 Tumbleweed 中的软件包进行太多更改，并且可能为 ALP 提供一个好的前进方向，但我会将这个决定留给 KDE 维护者
