为什么更新和升级的分离甚至存在?
我理解在apt
,命令update
更新可用软件包列表,但它不会升级已从这些软件包安装的软件。
我也明白, upgrade
升级我已安装的任何软件,如上所述,我使用update
了这个软件包。
Ubuntu / Debian开发人员分拆update
和upgrade
的原因是什么,而是使用一个命令来完成这两项任务?
这是关于Ubuntu开发人员的架构哲学的更多问题。
升级不是您可能需要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 update
每次运行是否有意义apt-get upgrade
? 不,再说一遍,因为我打算做的事情可能与apt-get upgrade
会发生冲突。
无论何时更改软件源,都必须运行命令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
的结果将提供诊断和解决问题的线索。
update
和upgrade
之间差异的历史实际上非常酷。
很久很久以前 – 大概在2000年左右,在Ubuntu存在之前的几年 – 带宽和磁盘空间更加有限……虽然与20世纪90年代中期相比有所扩大。 宽带刚刚开始,拨号仍然是上网的重要方式。 大磁盘仍然只有几百MB。 Apt是shiny的,新的,激进的和革命性的,建立在dpkg之上。
当您考虑它时,apt数据库是一个奇迹:它是来自所有已知存储库的所有软件的准确到分钟数据库。 它足够详细,足以计算依赖关系并识别可用的升级,但又足够小,可通过当时的拨号调制解调器进行传输,并存储在当时的小型驱动器上。 通过电话更新数据库可能需要几分钟才能建立良好的连接。 虽然现在已经很长时间了,但是手动查找包更新(在apt之前)可能会耗费数小时 。
当时,发行版的构建方式不同 – 没有持续集成,没有烟雾测试(好吧,根本没有太多测试!),构建农场刚刚开始。 升级必须比现在更频繁地恢复。 许多用户出于各种原因选择不升级某些软件包,或者今天仅选择某些升级(手动测试),以及明天进行其他升级。
在随后的15年左右的时间里, 工具没有太大变化,这就是为什么我们仍然有单独的update
和upgrade
操作。 随着发行版可靠性的提高, 用户工作流程也得到了发展,以前的许多源/更新/升级管理都被慢慢隐藏在自动化层( software-updater
, unattended-upgrades
)背后。
现代化软件包工具是Snaps和AppImage以及Flatpack最近出现的一个原因,但这是下一章。
出于多种原因,他们确实分开了。
一个例子是我发布并自行回答的问题: 如何使用GUI删除PPA? 。 在此屏幕上,我们要删除PPA而不是升级软件:
删除PPA后,GUI软件会自动运行sudo apt update
。 如果要从命令行中删除PPA,则需要在从源列表中删除PPA 后运行sudo apt update
。
如果没有单独的apt update
function,则无法删除PPA!
另一个例子是你需要从命令行运行sudo apt update
来刷新源代码。 然后,您可以找到可以升级而无需实际升级的内容:
$ apt list --upgradable Listing... Done conky-std/xenial 1.10.1-3 amd64 [upgradable from: 1.9.0-4] google-chrome-stable/stable 65.0.3325.181-1 amd64 [upgradable from: 63.0.3239.132-1] libxnvctrl0/xenial 390.48-0ubuntu0~gpu16.04.1 amd64 [upgradable from: 387.22-0ubuntu0~gpu16.04.1] nvidia-settings/xenial 390.48-0ubuntu0~gpu16.04.1 amd64 [upgradable from: 387.22-0ubuntu0~gpu16.04.1] peek/xenial 1.3.1-0~ppa23~ubuntu16.04.1 amd64 [upgradable from: 1.2.1-0~ppa20~ubuntu16.04.1]
查看输出,你可以决定让一个给定的软件包“固定”或“保留”,并且在下次运行“sudo apt upgrade”时不升级。如果有一个“更新/升级”过程,你将失去这些能力。
如果没有单独的apt update
您将看不到要升级的内容!
有人可能会问为什么要从正式的Ubuntu存储库下载该程序,然后安装apt
呢? 如果您先下载然后安装它而不是在一次操作中下载和安装,它会有什么不同?
在阅读完评论并思考更多内容后,我明白这是由于Unix哲学 ,一种模块化的哲学,基本上说“每个程序都做一件事”:首先下载,然后安装—每个动作都有自己的专用程序。
在没有分发的情况下,有一个命令更新升级的东西,如果它在那里,它只是我预测的预定义别名。 通过编辑〜/ .bashrc,也可以在Ubuntu上轻松设置这些别名。
更新用于重新同步存储库并解决其中的任何问题。 然后,当您升级时,实际上会升级已安装的软件包。 但是当您进行远程升级时,您将完全升级。 在Arch linux中,他们强调使用Syu进行全面升级。 你可以在Ubuntu中做同样的事情。 在完全升级中,您实际上解决了部分升级中可能出现的系统依赖性问题。
希望能帮助到你。 请原谅原始文本写在手机上。