最近，我在使用系统信息工具 Fastfetch 时，发现它无法检测到我系统上安装的玲珑包。我进行了一系列排查，并向 Fastfetch 项目提交了修复。在这个过程中，我们遇到了一个关于玲珑底层目录结构的疑问，希望能在官方社区得到解答。

事情的经过是这样的：

1. 我在 Debian 13 系统上，通过 Deepin 提供的玲珑仓库 (linglong:/CI:/release/Debian_13/) 安装了玲珑和一些应用。
2. 我发现 Fastfetch 的检测代码只检查了路径 /var/lib/linglong/repo/refs/heads/main，而我系统上的应用实际路径是 /var/lib/linglong/repo/refs/remotes/stable/main。
3. 我提交了一个 Pull Request，建议增加对新路径的检测。
4. Fastfetch 的维护者 CarterLi 在审核时，在一个 Deepin LiveCD 环境中发现，他那里的路径又是另一个：/var/lib/linglong/repo/refs/remotes/ci/main。

这引发了一个关键问题，也是我这次发帖求助的核心。

完整的背景和讨论可以在这个 GitHub Issue 中看到： https://github.com/fastfetch-cli/fastfetch/issues/1898

我想请教的问题

Fastfetch 的维护者 CarterLi 提出了一个非常好的问题：

"Should we enumerate all sub-paths in /var/lib/linglong/repo/refs/remotes? What's the difference of these paths?" (我们应该遍历 /var/lib/linglong/repo/refs/remotes 下的所有子路径吗？这些不同路径之间有什么区别？)

为了能让 Fastfetch 以及其他类似的第三方工具能够稳定、可靠地统计玲珑包的数量，我们想了解：

1. 在 /var/lib/linglong/repo/refs/remotes/ 目录下的这些不同子目录（例如 stable/main, ci/main 等）各自代表什么含义？
2. 这些目录结构是玲珑稳定、公开的接口的一部分吗？或者说，它们是随时可能变动的内部实现细节？
3. 对于一个想要统计所有已安装玲珑应用（不区分渠道）的外部工具来说，官方推荐的最佳实践是什么？
   • 是应该递归地遍历 /var/lib/linglong/repo/refs/remotes/ 目录下的所有子目录吗？
   • 还是有某个更上层的元数据文件或数据库可以查询？
   • 未来会有某个 ll-cli 的子命令（例如 ll-cli list --json 之类的）可以被程序稳定地调用和解析吗？

感谢大家的帮助和解答！