openSUSE:ALP/Workgroups/GrassyKnoll/Summary

这些是黑客周的结果

设计

基本概念是遵循我们对Leap所做的工作，创建一个“反向移植”仓库，其中包含来自Tumbleweed的社区软件包，以填补空白。这里的一个区别是SUSE的SLE仓库包含大约10,000个软件包，而ALP包含大约2,000个软件包，尽管如此，我们只需要添加大约350个软件包就能达到我们的初始目标。这包括yast和许多gnome构建依赖项，我们希望一旦它们可用，就能从ALP源中获取。但即使这个数量对于一个小团队来说也是可管理的，尤其是在软件包存在于Tumbleweed中的情况下。

一旦我们有了所需的软件包，我们就可以使用现有的工具（如kiwi）来创建用于测试的镜像，包括livecds。SUSE的Factory优先策略的最大好处是，有了正确的软件包，Tumbleweed中有效的一切也在这里有效。希望一旦我们知道SUSE计划如何构建他们的容器镜像，我们也可以使用相同的方法，并结合反向移植仓库来构建openSUSE社区镜像，如果有人有兴趣维护它们。我们本周的黑客周没有对此进行调查。

Lubos也花费了黑客周的大部分时间与d-installer合作，以查看它是否目前适用于处理我们所需的附加功能。

设计限制

虽然可以通过简单地以不同的方式构建镜像来规避ALP的许多限制，但由于ALP二进制文件是在没有某些功能（如AppArmor和NIS）的情况下构建的，因此很难避免其他一些设计决策。

结果

首先，我们有一个反向移植仓库，其中包含到目前为止我们所需的所有附加软件包，我们还有一个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仓库的反向移植软件包仓库，并使用机器人等。然后让维护者贡献他们希望维护的任何其他软件包。同时，设置镜像构建和openqa测试。与此同时，我命名空间下的反向移植仓库中的软件包大多链接到Factory（我会修复其余的），所以我将密切关注它们并检查它们是否仍然可以构建。如果您维护一个软件包并且对依赖项列表感兴趣，您还需要维护才能使其正常工作，请告诉我，我可以将其从Factory链接过来。但是，请注意，perl、python和ruby语言堆栈等的大部分内容尚未打包。此外，为了追求更轻量级的桌面，我想打包sway，因为它将很好地表明其他较小的wayland桌面需要什么。

名称是另一个需要考虑的问题，我们是否应该只使用Leap来表示SUSE的ALP产品的开源构建，或者我们应该做一些完全不同的事情？鉴于SUSE正在使用阿尔卑斯山的名字作为发布代码名，我选择做一些类似但不同的事情。这个项目应该比攀登阿尔卑斯山更极端，更像是在山丘上进行轻松的野餐或散步，所以这个原型项目的代号是Grassy Knoll，因为它听起来很酷，也许我玩了太多矮人要塞。无论如何，这可能不是该项目长期的最佳名称。

常见问题解答

• 为什么我们没有研究KDE？ - KDE有一个更大的软件包集。此外，我的初始目标之一是创建一个足够小的东西，如果我需要用几个人来维护它，主要用于我们自己的用例，我们就能做到。KDE不符合这个范围，但是从我们本周的测试来看，如果有人想维护KDE，它可能不需要对Tumbleweed中的软件包进行太多的更改，并且可能为ALP的KDE提供一个好的前进方向，但我将把这个决定留给KDE维护者