oma 1.28「助」您中秋快乐！

时隔三个月，oma 1.28 即将发布！

过去三个月，维护者们主要将工作集中在了针对现有功能和代码的整编修缮及初步的 oma-apt-pkg 实现上——换言之，oma 1.28 是一次技术性更新。当然，针对用户体验，本版还是带来了全新命令缺失 (command-not-found) 提示、多软件源并行下载、CI 环境支持修缮，并进一步增强了与 APT 行为的兼容性。

让我们来一起详细了解本版 oma 的新特性吧～

测试指南

安同 OS 可通过如下命令获取 oma 1.28 测试版更新：

oma topics --opt-in oma-preview

Debian、Ubuntu 及衍生版，Linux Mint、deepin 及 openKylin 用户可通过如下命令获取 oma（目前暂未区分测试源及稳定源，可直接获取 1.28 版更新）：

curl -sSf https://repo.aosc.io/get-oma.sh | sudo sh

如果您在测试 oma 的过程中遇到问题或有任何建议，欢迎您来社区各聊天群组与我们联系反馈。

更清晰：全新命令缺失提示

新命令缺失提示更注重引导和展示关键信息

您也许不知道，在安同 OS 中输入尚未安装或错误命令时收到的提示其实是 oma 负责的 (oma command-not-found) 。这一界面早在三年前的 oma 0.33.0 就已经引入，期间我们也有收到来自用户的反馈和批评，但一直苦于没能形成合适的设计，便没有修改过。

过去一月余，从几个 AI 提供的设计稿件中，经过断断续续的讨论，我们为 oma 1.28 实现了全新的命令缺失提示。新设计细化了提示模式：在命令精确匹配时，oma 会直接提示您需要安装的软件包；在有相似命令提示时，则会给出相关度最高的三个软件包（使用 Jaro-Winkler 距离算法），并引导您安装或查看其他匹配项。

那么，在软件包名匹配，而没有命令匹配的情况下呢？我们也在思考这个问题，兴许会在下一个更新中增加这一功能。

其他新特性

oma 1.28 还引入了两个非界面性的功能优化：

首先是多软件源并行下载行为优化。先前，oma 不论使用多少个软件源，均限制共使用 N 个下载线程（默认为 4，可通过 network_threads 配置项或 -t 参数自定义）。oma 1.28 修改了这一行为，在下载（如元数据刷新或软件包下载）过程中允许以软件源为单位开启 N × R 个下载线程，即如果开启了 5 个软件源，则默认可发起 20 个下载线程，更好地利用网络资源。

第二是 CI 变量支持。我们近期收到用户反馈，称 oma 在 Docker 等无 D-Bus 环境下难以设置非交互模式；因此，我们在 oma 1.28 引入了业界常用的 CI 变量（如 CI=1）探测支持。从 1.28 开始，oma 会自动探测这一变量并自动调整交互和输出模式，使其更适合在 Docker、持续集成等环境下使用。

问题修复

本版 oma 还引入了一些问题修复和行为修正：

• 修复了元数据刷新 (oma refresh) 过程中不会尝试不同压缩格式的元数据的问题：先前 oma 只会尝试编目（如 InRelease）中列出的第一个压缩格式的元数据文件，但若下载失败则会直接放弃；1.28 开始会综合编目文件中的不同压缩格式及 oma 的压缩格式优先级配置自动回落，行为更贴合 APT
• 解决了 systemd-logind(8) 不可用的环境下（如星霞 OS）鉴权工具判定不正确，导致无法提示鉴权的问题
• 解决了指定 --no-check-dbus 参数时仍尝试使用 systemd-run 鉴权，导致无 systemd-logind(8) 环境下无法鉴权的问题
• 修正了从 Acquire-By-Hash（即基于哈希校验和索引元数据的软件源）软件源在获取元数据失败时未正确回落到传统（即非哈希校验和索引的元数据目录）路径的问题，解决部分配置不良的软件源 Adoptium 无法使用 oma 刷新的问题

注意事项

oma 1.28 移除了对 Debian 11（代号“Bullseye”）的支持。Debian 对该版本系统的支持已于 2026 年 8 月 31 日终止。

已知问题

Wolfram Engine (wolfram-engine) 在 Raspberry Pi OS 软件源中的元数据错误将安装后大小 (Installed-Size) 条目写作了带小数的数字，如：

Package: wolfram-engine
Version: 15.0.1+202608182322
Architecture: arm64
Installed-Size: 5316364.474609375

而这与 Debian Policy Manual 第 5.6.20 节中提出的安装后大小数字“应将一般文件和符号链接大小的综合取整至 1KiB”的要求相悖，这也直接导致了 oma 无法解析对应元数据条目的问题。

目前遇到该问题的用户已将这一问题报告给 Wolfram 社区，有待答复。针对这一问题，我们可能会给 oma 引入对应的规避，仿照 APT 行为直接截断小数点后的数字。

技术性重构与 AI

oma 是社区首个大量使用 AI 辅助开发的项目，而 1.28 也是第一个由 AI 辅助开发的特性更新。

长期以来，oma 是由宇宙眼镜人 (Mag Mell)个人主导开发的项目，虽然时有社区贡献者和新朋友报告问题、实现功能，但个人推动技术性重构和重大功能需要大量动力。面对复杂的技术问题和架构调整需求，单人项目往往面临着“不敢想”和“没动力”，导致技术工作不断延后的问题。

如宇宙眼镜人在 AOSCC 2026 上介绍的，1.28 开发周期是 oma 大重构的开始。1.27 到 1.28 开发周期内最核心的技术实现便是 oma-apt-pkg，这是 oma 尝试替代长期依赖的 libapt-pkg 的开始，旨在提高多线程安全性、性能和引入更强的依赖解析控制，也将在未来作为解决安同 OS 长期存在的“滚挂”问题的手段之一；本版的 oma show 功能已切换到 oma-apt-pkg 实现。此外，1.28 还清理了多个功能板块（如 oma-console 实现的终端内容渲染功能、颜色输出控制系统和进度条等）的代码清理，并增强了 APT 兼容性和行为规范化（如基于对 APT 实现的考据，实现更规范的元数据时间日期格式解析）。

这些内容作为用户也许难以察觉，但 oma 作为安同 OS 的关键组件、部分 Debian 系发行版用户喜爱的增强工具和 APT 的替代品，需要不断解决兼容性和正确性问题、考据 APT 的行为。而要增强用户体验和系统集成度，恰恰也需要技术和架构性工作来支撑。1.28 到 1.29 相信也会是一个重重构、轻特性的开发周期，其中 oma-apt-pkg 对元数据刷新、依赖解析和安装过程的接管，以及 amo 集成仍会是关注重点。

当然，以上一切都是在遵守《安同开源社区 AI 辅助工具使用及披露约定》约定下进行的，希望 oma 能成为在 AI 的帮助下推动工作、在人类的监督下保障质量的实践范例…… 也希望以后的 PR 正文和注释能更有人味（笑）。