学习 C#

为 C# 开发者更新 Linux 软件包

Tim Corey

8m 25s

当您在Linux上开发C#应用程序时，您的系统包不仅仅影响操作系统。用于测试web应用程序的浏览器引擎、.NET SDK、共享库和安全补丁都通过包管理器提供。运行过期的包可能导致构建问题、漏洞或与最新.NET功能不兼容。

在他的视频"为C#开发人员更新Linux软件包"中，Tim Corey讲解如何使用图形的更新管理器和命令行保持Linux安装为最新，作为其更广泛的Linux上C#系列的一部分。在本文中，我们将介绍这两种方法，解开每个命令的实际作用，并解释保持系统更新对于.NET开发的重要性。

Linux软件包管理与Windows的差异

[0:00 - 0:38] Tim开始解决来自Windows的开发人员常见的障碍。在Windows上，每个应用程序通常会自行管理更新。 Visual Studio独立检查更新，同时Edge独立于打印机驱动程序进行更新。没有一个单一系统可以跟踪您机器上安装的所有内容。

Linux采用集中化的方法。像apt（高级包工具）这样的包管理器会跟踪从官方仓库安装的所有软件。当您运行更新时，apt会一次性查询每个已安装的软件包的仓库。浏览器更新、库补丁、SDK升级和安全修复等都通过相同的管道到达。

对于C#开发者来说，这有实际影响。您的.NET运行时、您的HTTPS调用所依赖的OpenSSL库以及您的应用程序链接的系统级依赖项都由此系统管理。如果您首次在非Windows平台上开始使用C#，了解包管理器的工作原理可以帮助您避免未来的神秘构建故障。单个apt upgrade保持整个堆栈对齐，这一点在Windows上需要跨多个独立更新器进行协调。

图形界面：更新管理器

[0:38 - 1:34] 对于偏好可视化工作流程的开发人员，Tim首先介绍更新管理器。Linux Mint包含一个类似于Windows更新的工具。任务栏右下角的小图标打开它，您将看到具体将更新哪些内容：Microsoft Edge、Firefox、curl、libssh等等。每个条目显示当前版本、新版本和下载大小。

所有包默认被选中，但您可取消勾选项目，以便跳过特定更新。如果您的项目需要特定版本的工具且不希望在冲刺中更改，这是很有用的。

您点击"安装更新"，在提示时输入密码并等待过程完成。存在密码提示是因为修改系统包是系统管理操作，我们会在下节中讨论。

GUI在一件事上表现不错：根据风险级别分类更新，并对可能影响系统稳定性的更改更加保守。对于刚接触Linux的开发者，他们只想保持环境健康而不担心细节，更新管理器是一个坚实的默认选择。

理解sudo

[1:34 - 1:51] 在移动到终端之前，Tim花时间解释sudo，因为它出现在每个命令行包操作中。在您开始键入之前了解它的作用是值得的。大多数Windows用户账户默认是管理员账户，允许您完全访问安装、删除和修改系统软件。 Linux采取相反的方法：您的账户运行在有限权限下，仅在需要时才升级为管理员权限。

以sudo为命令前缀会触发密码提示以验证您的身份。一旦经过身份验证，该命令以root权限执行，然后权限会恢复为正常。包管理（安装、删除或更新软件）是一个系统级操作，可能会影响计算机上的每个应用程序，因此使用明确的sudo前缀可以确保您不会在本意为其他操作时意外修改系统包。

如果您使用过Windows，可以视作类似于以管理员身份运行Visual Studio，不同的是在Linux上，您只针对单个命令进行提升，而不是整个应用程序。这是一种更有针对性的方法。

命令行：apt update

[1:51 - 2:28] 在讲解完sudo后，Tim转向终端。在那里工作可以为您提供对更新过程的更细粒度的控制，他按顺序走过三个命令。了解每个命令的作用很重要，因为正如他所指出，命名具有欺骗性。

第一个命令是：

sudo apt update

sudo apt update

SHELL

普遍的假设是该命令更新软件包。但并非如此。 apt update刷新软件包索引，即可用软件的本地目录。随着时间推移，该目录会随着维护者发布新版本而过期，因此运行此命令从仓库服务器下载最新版本。您的机器上没有软件更改。它纯粹是信息收集步骤。

运行之后，apt报告有多少软件包有更新版本可用。您可以在提交任何更改之前检查完整列表：

apt list --upgradeable

apt list --upgradeable

SHELL

这为您提供了每个软件包的逐行视图，其中包括当前和新版本号。如果您在这台机器上使用.NET，这是您可能会发现SDK更新、运行时补丁或您应用程序所依赖库的更改的地方。了解您的机器上正在使用的.NET版本便于您决定某个特定升级是否可以安全应用或需要首先进行测试。

命令行：apt upgrade

[3:01 - 3:40] 一旦索引被刷新，Tim转到第二个命令——那个实际安装更新版本的命令：

sudo apt upgrade

sudo apt upgrade

SHELL

注意命名：upgrade是更改包的操作。这种两步划分是有意为之。它将"查看可用内容"步骤与"应用更改"步骤分开，让您有时间在变动之前进行审阅、研究或备份。

在后台，upgrade遵循严格的规则，限制其将做什么和不做什么。它下载并安装您系统上已有软件包的更新版本，但绝不会移除现有软件包或安装先前不存在的新软件包。当较新版本需要未安装的依赖项时，upgrade会阻止该包，而不是自动引入新的依赖项。

好处是可预测性。保持您的.NET堆栈更新很重要，但以可控方式进行也很重要。系统会向您提示即将更改的摘要并要求您确认后才会继续，因此在未经您的明确许可之前不会发生任何事情。

命令行：apt full-upgrade

[3:40 - 4:19] 应用安全更新后，Tim引入了第三个命令来处理一切upgrade故意保留的内容：

sudo apt full-upgrade

sudo apt full-upgrade

SHELL

upgrade故意避免的情况。如果包更新需要安装新的依赖项或删除冲突的包，full-upgrade将执行此操作。内核升级、主要系统库更改和操作系统级别补丁在此处应用。

运行这个作为一个独立步骤为您提供了分层的方法。如果在复杂的依赖解析过程中出现问题，您已经应用了简单的更新，只需要故障排除较复杂的问题。

对于在Linux上编译C#应用程序的团队而言，这种分阶段的工作流程尤其重要。在自动化CI/CD环境中，您可能选择仅运行full-upgrade保留用于计划的维护窗口，在更深入的系统更改后您可以验证一切仍然可以编译并通过。

包计数不同的原因

[2:28 - 3:01] 经常让人困惑的是：更新管理器可能显示23个更新，而命令行报告79个软件包。这些不是不同的更新集；这是相同系统的不同计数方式。

GUI将相关软件包分组为逻辑单元。在更新管理器中，一个"Firefox更新"实际上可能由Firefox二进制文件、其本地化包、其依赖的共享库和一个配置包构成，每个包都由apt单独追踪。因此，更新管理器呈现为一个更新的内容，apt则列为四个或五个独立的软件包升级。

一旦您知道这一点，差异就不会再让人困惑。有人可能会说"我有100个软件包要升级"，这和您的更新管理器显示的30个更新是一回事。

Flatpak: 一个独立的软件包管理器

[5:56 - 6:41] 有一个容易忽视的地方：Linux 可以安装多个包管理器，而 apt 只知道它管理的包。 Flatpak 是一种替代方案；它是一个基于沙箱的系统，将应用程序及其依赖项打包在一起，与系统其余部分隔离开来。

如果您通过Flatpak安装了软件，运行apt upgrade不会影响这些应用程序。您需要单独更新它们：

flatpak list
flatpak update

flatpak list
flatpak update

SHELL

flatpak update将这些包更新到最新版本。定期检查是个好习惯，尤其是如果您通过它安装了IDE、数据库工具或通信应用程序。

在 Linux 上，软件可以通过 apt、Flatpak、Snap，甚至手动安装到达。每个都有自己的更新机制，所以一个全面的更新程序应该考虑所有这些。如果您习惯每个应用程序都有自己的更新程序，这里的关键区别是您需要知道哪个包管理器拥有哪个软件，并为每个软件运行正确的更新命令。

您应该使用哪种方法？

[4:19 - 5:32] Tim 认为这两种方法都是有效的，正确的选择取决于您的工作流程。如果您更习惯于可视化界面，更新管理器通过点和点界面处理与 apt 相同的更新。您无需记住命令或担心以错误的顺序运行步骤。话虽如此，习惯使用命令行的理由也很充分：自动化。您可以创建一个简单的 shell 脚本来运行完整的更新序列，并使用 cron 计划每周执行。一个三行脚本可以让您的系统保持最新，而无需您操心，这是一种随着时间推移会累积回报的小投资。

除了自动化之外，命令行还允许您根据上下文选择性地应用某些升级级别，或将输出管道传输到其他工具进行分析。这些选项在图形用户界面中是不可用的。

审核您安装的软件包

[7:16 - 7:54] 更新过程也有一个有用的副作用：审查您的更新列表可以兼作对系统上已安装内容的审核。当您看到更新队列中的一个包，值得问一下您是否仍然需要它。

您可能会看到更新列表中的 Firefox 而您主要使用 Edge，或反之。为 web 应用程序的跨浏览器测试保留两个浏览器安装是有意义的，但更广泛的原则是更新列表显示了您的开发环境的完整足迹。以前项目中的陈旧工具、被拉进来的开发库依赖项却从未清理过、您半年前忘记自己安装的包：这些全部会出现在这里。

这种整理会带来超出预期的好处。一个干净的开发环境更容易跨团队成员复制，也更容易容器化，并且不太可能产生"在我机器上工作"的漏洞。如果您的 Linux 设备上安装的软件包未包含在您的 Dockerfile 中，您可能依赖于不会在生产环境中存在的东西。熟悉将 C# 应用程序部署到 Docker能让本地包与生产环境之间的连接更加具体。