我似乎无法弄清楚这一点。我执行了“sudo apt update”，它报告了 1 个可用更新：
sudo apt list --upgradable -a
Listing... Done
dmidecode/jammy-updates 3.3-3ubuntu0.1 arm64 [upgradable from: 3.3-3]
dmidecode/jammy,now 3.3-3 arm64 [installed,upgradable to: 3.3-3ubuntu0.1]
然后我执行“sudo apt upgrade”并得到以下结果：
sudo apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
dmidecode
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
有人知道为什么升级无法安装吗？我该如何更新此包？
答案1
有人知道为什么升级无法安装吗？
是的——TLDR：一种称为分阶段更新的东西。
这里有一份稍长的答案。假设新版本的软件包中有一个错误。如果新版本一次性发布给所有人，维护人员将无法承受所有这些用户的错误报告，而且会有很多用户受到影响，有些人可能在一段时间内不会再更新他们的错误软件包 - 这是很糟糕的。因此，维护人员可以做的是将更新配置为分阶段更新。这意味着少数用户首先获得它，他们充当所谓的“第一阶段测试人员”，为下一轮人员 - “第二阶段测试人员”扫清道路，这是一个稍大一点的群体，依此类推。这样，希望在早期阶段发现更多错误，然后在错误之后的报告-修复-redpeploy-更新周期中对维护人员和用户的影响较小。或者，如Ubuntu 维基，分阶段更新已完成：
这样就可以在向所有人推送更新之前检测到严重的回归问题，并停止该过程。目标是使回归问题影响到我们较小比例的用户群。
我该如何更新这个包？
TLDR：不要。就让它保留。准备就绪后，它会在您运行命令时apt upgrade或作为自动更新的一部分进行更新。
如果您确实需要最新版本的软件包，那么似乎有一种方法可以绕过分阶段更新，但我只会在您绝对需要新版本时才会这样做：
贡献者控制台的“更新”面板应该允许测试人员选择退出发布后的分阶段更新，或者选择加入发布前的分阶段更新（以测试分阶段机制本身）。