Debian软件包管理的前提条件

Debian软件包管理是Debian操作系统中一个非常重要的组成部分，它提供了一种方便、高效的方式来安装、更新和卸载软件。在使用Debian软件包管理器之前，我们需要了解一些前提条件，以确保我们的系统能够正确地使用这个工具。

一、 Debian软件包管理

许多远程镜像站提供了HTTP和FTP的方式来访问Debian档案库，也可以使用CD-ROM/DVD。目前，Debian的软件包管理系统是高级软件包工具（APT），它能够使用所有这些资源。Debian软件包管理系统，当使用适当时，可以让用户从档案库安装统一设置的二进制软件包到系统中。现在，有71141个可用于amd64架构的软件包。

Debian软件包管理系统具有丰富的历史，有许多可供选择的前端用户程序和后端访问方式。现在，我们推荐下列这些：

• apt(8)用于所有的交互式命令行操作，包括软件包的安装、移除和版本升级；

• apt-get(8)用于从脚本中调用Debian软件包管理系统。它在apt不可用时也可作为一个备选选项（常见于较旧的Debian系统）；

• aptitude(8)使用一个交互式的文本界面来管理已安装的软件包和搜索可用的软件包。

Debian 软件包管理工具列表：

二、软件包配置

下面是 Debian 系统软件包配置的一些要点：

1、Debian 尊重系统管理员的手动配置。换句话说，软件包配置系统不会为了方便而去更改那些配置。

2、每个软件包都带有自己的配置脚本，它使用标准用户接口 debconf(7) 来帮助软件包初始化安装过程。

3、Debian 开发者通过软件包配置脚本，尽力使能有一个完美的升级体验。

4、系统管理员可以使用软件包工具的全部功能。但在默认的安装中会禁用那些具有安全风险的。

5、如果手动激活了一些具有安全隐患的服务，有责任遏制风险。

6、高深的配置可以由系统管理员手动启用。这可能会对用于系统配置的通用流行帮助程序造成干扰。

三、基本注意事项

不要从任何的混合套件中安装软件包。它可能会打破软件包的一致性，这需要要深厚的系统管理知识，例如 ABI 编译器、库版本和解释器特性等等。

Debian 系统管理员中的新手应该保持在只进行安全更新的 stable 版本。直到十分了解 Debian 系统前，应当遵循下列的预防措施：

1、在 源文件 中不要包含 testing 或 unstable 。

2、在 源文件 里不要在标准的 Debian 中混合使用其它非 Debian 的档案库，例如 Ubuntu 。

3、不要建立 “/etc/apt/preferences” 。

4、不了解会造成的全部影响，就不要通过配置文件改变软件包管理工具的默认行为。

5、不要使用 “dpkg -i random_package” 安装任何软件包。

6、绝不使用 “dpkg –force-all -i random_package” 安装任何软件包。

7、不要删除或修改 “/var/lib/dpkg/” 中的文件。

8、不要让从源码直接安装的程序覆盖系统文件。如果需要的话，将它们安装到 “/usr/local” 或 “/opt” 中。

对 Debian 软件包管理系统，违背上面的预防措施，会导致不兼容影响，可能会使系统无法使用。运行关键任务服务器的严谨的 Debian 系统管理员，应该使用额外的预防措施。

9、没有在安全的条件下使用特定的配置进行彻底地测试，就不要从 Debian 安装任何软件包（包含安全更新）。作为系统管理员要对系统负责到底。Debian 系统长久的稳定史并无法保证什么。

四、持续升级

对于生产服务器，建议使用带有安全更新的 stable 套件，对于只进行有限管理的桌面 PC 也是同样如此。

这个列表面向 自己管理的 桌面环境：

1、使用 testing 版，实际上，它是自动滚动发布的，由 Debian 档案库的 QA 质量架构来管理，比如：Debian 持续集成、只上传源代码实践 和 库转换跟踪。在 testing 版中的软件包被更新得足够频繁来提供全部最新的特性。

2、在源列表里面设置 testing 版相应的代码名为套件名（在 bookworm-作为-stable 版的发布周期时，是”trixie”）。

3、大概在主版本发布一个月后，仅仅在自己评估了形势后，才手动更新 源文件 里的这个代码名到新的版本号。对于这个更新，Debian 用户和开发者邮件列表也是好的信息来源。

使用 unstable 版是不推荐的。unstable 版对开发者 调试软件包合适，但对普通的桌面使用而言，会有使暴露在不必要的风险中的倾向。 尽管 Debian 系统的 unstable 版在大多数时候看起来都非常稳定，但会有一些软件包问题，并且它们中的一部分是不容易解决的。

这里有一些基本预防措施意见，确保简单快速地从 Debian 软件包的 bug 中恢复。

• 通过将 Debian 系统的 stable 版安装到另一个分区，可以使系统能够进行双启动；

• 制作安装 CD 便于用于 救援启动；

• 考虑安装 apt-listbugs ，这可以在升级之前检查 Debian Bug 跟踪系统（BTS） 的信息；

• 对软件包系统的基础设施有足够的了解来解决问题。

如果无法做到这些预防措施中的任何一个，那可能还没做好使用 testing 和 unstable 版的准备。

五、Debian档案库基础

让我们从系统用户的角度来看看 Debian 档案库。对于系统用户，是使用 APT 系统来访问 Debian 档案库。APT 系统定义它的数据源作为源列表，在 sources.list(5) 里面描述。对于使用典型的 HTTP 访问的 bookworm系统，单行格式的源列表如下：

可替代的，相等的使用 deb822 格式的源列表如下：

源文件 的关键点如下。

1、单行格式

它的定义文件在”/etc/apt/sources.list”文件和”/etc/apt/sources.list.d/*.list”文件里面；

• 每一行定义了 APT 系统的数据源；

• “deb” 的那行定义了二进制软件包；

• “deb-src” 的那行定义了源代码软件包；

• 第一个参数是 Debian 档案库的根 URL ；

• 第二个参数是发行版名称，可以使用套件名或代号；

• 第三个和之后的参数是 Debian 档案库的有效档案库范围名称。

2、Deb822 格式

• 它的定义文件在”/etc/apt/sources.list.d/*.source”文件里；

• 由空格隔开的每个多行块，定义了 APT 系统的数据源；

• “Types:” 章节定义列表类型，即”deb” 和 “deb-src”；

• “URIs:”章节定义 Debian 档案库 URI 的根地址；

• “Suites:”章节定义了发行版名称列表，名称可以使用套件名或代号；

• “Components:” 章节定义 Debian 档案库中有效档案库名称列表。

如果只是用 aptitude，它不访问源代码相关的元数据，“deb-src”定义可以安全地省略。这可以加速档案库元数据的更新。

“#” 开头的行是注释，被忽略。

这里，我倾向于使用代号 “bookworm”或”trixie”来代替套件名 “stable”或”testing” ，以避免下一个 stable 版本发布时出现意外。

如果在上述的例子中，使用了 “sid” 代替 “bookworm” ，那么源列表中用于安全更新的 “deb: http://security.debian.org/ …” 这行或它的 deb822 等价内容就不需要了。因为没有用于 “sid” （unstable）的安全更新的档案库。在 bookworm 发布后，下面是配置文件所使用的 Debian 档案库站点的 URL 和套件名或代号的列表。

Debian 档案库站点列表：

Debian 归档区域（area）列表：

上述软件包的数量是 amd64 架构的。main 区域提供 Debian 系统。通过把浏览器指向档案库 URL，这些 URL 在 dists 或 pool 之后是各不相同的，Debian 档案库能够被有规划的组织。

发行版可以用套件或代号来指定。发行版在许多文档中也被当做是套件的同义词。套件和代号的关系总结如下。

套件和代号的关系：

在较严格的 Debian 档案术语，“部分 section”这一词特指按应用领域来分类的软件包类别。（但是，主要部分 (“main section”) 这一词有时会用来描述 Debian 档案区中，名为”main 主要”的区域 。）

Debian 开发者（DD）每次上传软件包到 unstable 档案库（通过 incoming 处理），都必须确保上传的软件包与最新的 unstable 档案库中的最新软件包兼容。如果 DD 故意打破重要的库升级等的这种兼容性，这通常会在 Debian 开发者邮件列表等进行公告。

在 Debian 档案库维护脚本将软件包从 unstable 档案库移动到 testing 档案库前，档案库维护脚本不仅检查时间（约10天）和软件包的 RC bug 报告的状态，还尝试确保它们可以和最新的 testing 档案库中的软件兼容。这个过程使得testing 档案库非常正确可用。

通过由发布团队领导的逐步冻结档案库的过程，并进行一些手动干预，使 testing 档案库完全一致，无缺陷。然后，将旧的 testing 档案库的代码名称分配给新的 stable 档案库，并为新的 testing 档案库创建新的代码名称。新的 testing 档案库最初的内容和新发布的 stable 档案库的内容完全相同。

unstable 和 testing 档案库都可能会遭受由以下几个因素导致的临时的小故障：

• 损坏的软件包被上传到档案库（多见于 unstable ）；

• 延迟接受新的软件包到档案库（多见于 unstable )；

• 档案库时间同步问题（ testing 和 unstable ）；

• 手动干预档案库，例如移除软件包（多见于 testing ）等。

因此，如果决定使用这些档案库，应该能够修复或忍受这些类型的小故障。

注意：

• 在新的 stable 版本发布后的几个月，大多数桌面用户应该使用带有安全更新的 stable 档案库，即使他们通常使用 unstable 或 testing 档案库。在这个过渡期中，unstable 和 testing 档案库不适合大多数人。使用 unstable 档案库的系统是很难保持良好的工作状态的，因为它会遭受核心软件包的大量升级狂潮。 testing 档案库不大有用，因为它包含有和没有安全支持的 stable 档案库相同的内容（Debian testing 安全公告 2008-12）。一个月左右的时间后， 如果仔细点的话， unstable 档案库或许可以使用；

• 跟踪 testing 档案库时，由一个已移除的软件包引起的问题通常可以安装 unstable 档案库中相同的软件包（已修复 bug )来解决。

六、100%自由软件

Debian 是100%的自由软件，因为：

• Debian 默认只安装自由软件，这尊重了用户的自由；

• Debian 在 main 中只提供自由软件；

• Debian 建议只运行来自 main 的自由软件；

• 在 main 中的软件包，没有依赖或推荐在 non-free 或 non-free-firmware 或 contrib 中的软件包。

有人想知道下列的两个事实是否互相矛盾。

• “ Debian 将始终是 100% 的自由软件”；

• Debian 服务器上有一些 non-free-firmware、non-free 和 contrib 软件包。

因为下列原因，这并不矛盾。

• Debian 系统具有100%的自由，并且它的软件包位于 Debian 服务器的 main 区域；

• Debian 系统之外的软件包位于 Debian 服务器的 non-free、 non-free-firmware和 contrib 区域。

在 Debian 社群契约的第4条和第5条对这进行了明确的解释：

• 我们将优先考虑我们的用户及自由软件：

我们由我们的用户及自由软件社群的需要所导向。我们将优先考虑他们的利益。我们将在多种计算环境中支持我们的用户的操作需要。我们不反对在 Debian 系统上使用非自由软件，我们也不会尝试向创建和使用这部分软件的用户索取费用。我们允许他人，在没有我们的资金的参与下，制造包括 Debian 以及商业软件的增值套件。为了达成这些目标，我们将提供集成的、高质量的、100%自由的软件，而不附加任何可能阻止在这些方面使用的法律限制。

• 哪些作品不符合我们的自由软件规范：

我们知道，某些我们的用户需要使用不符合 Debian 自由软件指导方针的作品。 我们为这些作品，在我们的档案库中留出了”non-free”、”non-free-firmware”和”contrib”目录。在这些目录下的软件包，并不属于 Debian 系统 尽管它们已被配置成可以在 Debian 下使用。我们鼓励光盘制造商阅读这些目录下的软件的许可证，以判断他们是否可以在光盘中发行这些软件 。所以，尽管非自由软件并非 Debian 系统的一部分，我们仍支持它们的使用，并且我们为非自由软件提供了公共资源 (诸如我们的缺陷跟踪系统以及邮件列表)。Debian 官方媒介可以包括固件，固件不是 Debian 系统的一部分，这是一个例外，能够让 Debian 用于需要这些固件的硬件上。

用户应该了解使用 non-free 、non-free-firmware和 contrib 中的软件包所需要冒的风险：

• 使用类似的软件包会失去自由；

• 失去 Debian 对软件包的支持（这些软件包无法访问源代码，Debian 不能进行完全的支持。）；

• 污染100%自由的 Debian 系统。

Debian 自由软件指导方针为 Debian 设立了自由软件标准。Debian 对软件包中的软件做了最广泛的解释，包含文档、固件、图标和图形数据。这使得 Debian 的自由软件标准非常严格。

典型的 non-free、 non-free-firmware和 contrib 软件包包含了下列类型的自由分发的软件包：

• 在GNU Free Documentation License下的文档包 ，包含不变的部分 ，比如GCC 和 Make的。 （大多数都可以在non-free/doc找到 .)；

• 包含没有源代码的二进制数据的固件软件包，例如在 第 9.10.5 节 “硬件驱动和固件” 中作为 non-free-firmware 列出的软件包；

• 游戏和字体软件包，对商业使用和/或内容修改进行了限制。

请注意，non-free、non-free-firmware 和 contrib 软件包的数量少于 main 软件包的2%。允许访问 non-free、non-free-firmware 和 contrib 并不会模糊软件包的来源。使用 aptitude(8) 的全屏交互式界面可以提供完全的可见性和完全的控制，可以让决定安装来自某个部分的软件包，来使系统保持自由。

七、软件包依赖关系

Debian 系统通过其控制文件字段中的版本化二进制依赖声明机制来提供一致的二进制软件包集合。下面有一些它们的简单定义。

• “依赖”：绝对的依赖，所有在这里列出的软件包都必须同时或提前安装。

• “预依赖”：类似于 Depends，但列出的软件包必须提前完成安装。

• “推荐”：这里表示一个强，但不是绝对的依赖关系 。大多数用户不会想要这个包，除非在这里列出的所有包都已经安装。

• “建议”：较弱的依赖。这个软件包的大多数用户可能会从安装所列的软件包中受益，但没有它们也可以有适当的功能。

• “增强”：这里表明一个像建议的弱依赖关系，不装也没关系。

• “破损”：表明一个软件包不兼容一些版本规范。一般的解决方法就是升级列出的所有软件包。

• “冲突”：这表明了绝对的不兼容。为了安装这个软件包必须移除所有列出的软件包。

• “替代”：这表明这个文件安装的文件会替代所列的软件包的文件。

• “提供”：表明这个软件包会提供所列的软件包所有的文件和功能。

请注意，同时将 “Provides” 、“Conflicts” 和 “Replaces” 定义到一个虚拟的软件包是一个明智的配置。这确保了在任何一个时间只能安装一个提供该虚拟包的真正软件包。

八、包管理的事件流

这是 APT 提供的软件包管理的简单事件流摘要。

1、更新（“apt update”、“aptitude update” 或 “apt-get update”）：

• 从远程档案库获取档案库元数据

2、重建和更新 APT 使用的本地元数据

升级（“apt upgrade” 和 “apt full-upgrade”，或 “aptitude safe-upgrade” 和 “aptitude full-upgrade”，或 “apt-get upgrade” 和 “apt-get dist-upgrade”）：

• 选择候选版本，它所安装的软件包通常都是最新的可用版本；

• 解决软件包依赖关系；

• 如果候选版本与已安装的版本不同，会从远程档案库获取所选择的二进制软件包；

• 解包所获取的二进制软件包；

• 运行 preinst 脚本；

• 安装二进制文件；

• 运行 postinst 脚本。

3、安装（“apt install …”、“aptitude install …” 或者 “apt-get install …” ）：

• 选择命令行中列出的包；

• 解决软件包依赖关系；

• 从远程服务器获取已选二进制包；

• 解包所获取的二进制软件包；

• 运行 preinst 脚本；

• 安装二进制文件；

• 运行 postinst 脚本。

4、移除 （”apt remove …”, “aptitude remove …” 或 “apt-get remove …”）：

• 选择命令行中列出的包；

• 解决软件包依赖关系；

• 运行 prerm 脚本；

• 移除已安装的文件，除了配置文件；

• 运行 postrm 脚本。

5、清除 （”apt purge”,“aptitude purge …” 或 “apt-get purge …”）：

• 选择命令行中列出的包；

• 解决软件包依赖关系；

• 运行 prerm 脚本；

• 移除已安装的文件，包含配置文件；

• 运行 postrm 脚本。

九、包管理的第一个回应

请输入以下命令：

可能需要安装以 “-doc” 后缀命名的对应文档软件包来获取详细的信息。如果在使用一个特定的软件包时出现了问题，一定要首先检查 Debian bug 跟踪系统（BTS） 网站。

解决特定软件包问题的主要网站：

使用 Google 搜索，在关键字中包含 “site:debian.org”，“site:wiki.debian.org”，“site:lists.debian.org” 等等。当要发送一份 bug 报告时，请使用 reportbug(1) 命令。

十、挑选Debian软件包

当遇到2个以上的类似的软件包时，先前没有经过反复的尝试，不知道安装哪一个的时候，应该用常识来判断。我认为以下几点是首选的软件包应该具有的特征。

• 重要性：是 > 否；

• 类型：main > contrib > non-free；

• 优先级：需要 > 重要 > 标准 > 可选 > 额外；

• 任务：在任务下有软件包的列表信息，例如 “桌面环境”；

• 软件包是被与之有依赖关系的软件包所选择的（例如 gcc 依赖 gcc-10）；

• 流行度：在投票或者安装指数上有着更高的分数；

• 更新日志：维护者经常的更新；

• BTS (缺陷跟踪系统):没有 RC 级别的缺陷（没有危险、重大严重的缺陷）；

• BTS (缺陷跟踪系统):有维护者对缺陷报告反馈；

• BTS (缺陷跟踪系统): 有着更多的近期修复的 bug 数目；

• BTS (缺陷跟踪系统):遗留的非严重（non-wishlist）缺陷数量较少。

Debian 是一个使用分布式开发模式的志愿项目，它的档案库包含了许多不同关注点和不同质量的软件包。必须做出自己的选择。

十一、不一致的协作

无论决定使用哪个 Debian 系统套件，仍然希望运行在那个套件里不存在的程序版本。即使在其它 Debian 套件里面，或者在其它非 Debian 的资源里面，找到这个程序的二进制软件包，它们的要求可能和目前的 Debian 系统不一致。

在单独安装这类不同步的软件包之前，需要查找所有存在的和目前 Debian 系统兼容的安全技术替代方案。

1、使用相应的沙盒化的上游二进制软件包来安装这样的程序。

• 许多常见的 GUI（图形用户界面）程序，比如 LibreOffice 和 GNOME 应用，会有 Flatpak、Snap 或 AppImage 软件包存在。

2、建立一个 chroot 或类似的环境来在里面运行这样的程序。

• CLI 命令能够在和它兼容的 chroot 下轻松执行。

• 不重启机器，能够轻松的尝试多个完整的桌面环境。

3、自己构建需要的二进制软件包版本，和目前 Debian 系统兼容。

• 这是一个 不轻松的任务。