为什么会存在更新和升级的分离？

Question

我知道在 中apt，该命令会update更新可用软件包的列表，但它不会升级已从这些软件包中安装的软件。

我也知道upgrade升级我已经从我更新的软件包中安装的任何软件，update如上所述。

Ubuntu/Debian 开发人员进行这种拆分update并upgrade使用一个命令来完成两项任务的原因是什么？

这更多是关于 Ubuntu 开发人员的架构哲学的问题。

Answer 1

升级不是您可能需要的唯一一次apt-get update，而且我不想每次只想更新软件包列表时都升级。

一个apt-get upgrade运作良好，可以依赖于apt-get update正在运行的时间不长，但随后即是真实apt-get remove和apt-get install的！所有这些都应该暗示apt-get update吗？当然不是！作为一个简单的资源效率和设计清洁问题，如果一个操作与多个其他操作相同，则应该将其排除。

相反，鉴于这一点，apt-get remove并且apt-get install可能还取决于apt-get update最近运行是否成功完成，apt-get upgrade对于每次运行apt-get update是否有意义？不，再一次，因为我打算做的事情很可能与apt-get upgrade将要做的事情发生冲突。

Answer 2

无论何时更改软件源，都必须运行该命令sudo apt update以刷新可用软件列表。然后，您可以在刚刚添加和/或安装它们的新软件源中搜索可用软件包。

该命令sudo apt upgrade相当于使用 Software Updater 应用程序升级已安装软件包列表的终端。这与添加新软件源、更新可用软件列表以包含来自新软件源的软件包以及从您刚刚添加的新软件源安装新软件包的正常工作流程不同，因此更加方便并且不那么令人困惑，sudo apt update并且sudo apt upgrade是单独的命令。

分离也不那么令人困惑sudo apt update，sudo apt upgrade因为当您sudo apt update成功运行时，您已经确认您有互联网连接。如果sudo apt upgrade之后运行出现问题，则问题更可能是包管理问题，而不是互联网连接问题，结果sudo apt upgrade将为诊断和解决问题提供线索。

Answer 3

之间的差异的历史update和upgrade实际上是很酷。

很久很久以前——比如大约 2000 年左右，在 Ubuntu 出现之前的几年——带宽和磁盘空间更加有限......尽管与 1990 年代中期相比，空间广阔。宽带刚刚起步，拨号仍然是上网的重要方式。大磁盘仍然只有几百 MB。Apt 是闪亮的、新颖的、激进的和革命性的，建立在 dpkg 之上。

仔细想想，apt 数据库是一个奇迹：它是所有已知存储库中所有软件的精确到分钟的数据库。它足够详细，易于计算依赖关系并识别可用的升级，但又足够小，可以通过当时的拨号调制解调器进行传输并存储在当时的小型驱动器上。如果连接良好，通过电话更新数据库可能需要几分钟时间。虽然现在已经很长时间了，但手动查找包更新（在 apt 之前）可能会花费数小时。

那时，发行版的构建方式不同——没有持续集成，没有冒烟测试（好吧，根本没有太多测试！），构建农场才刚刚开始。升级必须比现在更频繁地恢复。许多用户出于各种原因选择不升级某些软件包，或者只选择今天升级某些升级（手动测试），明天再升级。

在随后的 15 年左右的时间里，工具没有太大变化，这就是为什么我们仍然有单独的update和upgrade操作。的用户的工作流程已经演变为发行可靠性有所提高，和多源/更新/升级管理的曾经是手动已经慢慢隐藏自动化的层后面（software-updater，unattended-upgrades）。

使软件包工具现代化是 Snaps、AppImage 和 Flatpack 最近出现的一个原因，但这是下一章。