来自的讨论这个帖子让我对 Debian 和 Arch 包管理之间的差异感到好奇。另外，人们倾向于说 Arch 非常轻量级，所以我想知道这与包管理有什么关系。可能是因为 Debian 对待推荐默认情况下作为硬依赖项？
您是否还可以提及两个包管理器之间的灵活性/功能：两者中的哪一个可以让您做更多的事情。
我知道 Debian 包管理系统上可用的某些功能在 Arch 系统上是无关的，因为 Arch 有一个套件，而 Debian 有多个套件（例如，APT 固定和高级依赖处理），因此请比较以下功能：适用于两个系统（即假设对于 Debian，我只使用不稳定）。
答案1
我从几周以来就经常使用 arch，并且不是这个主题的专家，所以这个答案绝不是详尽的，只是我注意到的关于“灵活性/功能”的几点：
这只是一个印象，但 pacman 的设计/架构似乎更现代、更简单。至少需要处理的工具要少得多。虽然我不知道 apt 源代码，但我只是碰巧查看了 libalpm 代码（pacman 的底层库）来制作一个非常简单的补丁，它看起来干净且易于理解。
它也非常快（由于优化，也可能通过关心一些事情（见下文））。最后一个版本（pacman 3.5，几天前）尝试通过减少涉及的数据库文件的数量来提高性能。
虽然 arch 面向使用二进制包，但它在从源代码构建包时也具有优势，其构建系统类似于 BSD 的端口 (ABS)。
创建软件包非常简单快捷，只需在 PKGBUILD 文件中添加几行即可完成，无需像 Debian 软件包那样处理控制/规则/版权/更改日志/任何内容。只需在 Web ui 上单击几下，您的包就会与 AUR（Arch 用户存储库）上的每个人共享。
我在 Debian 中得到的东西，而不是在 arch 中得到的东西：
触发器/挂钩（是什么让 apt 更新图标缓存、mandb 或其他什么，只需查看包安装文件的位置，不需要打包器做任何事情）（似乎有计划来实现这一点）。
debconf （没什么大不了的，顺便说一句，通过强迫我手动做事，它迫使我知道到底做了什么）和正确处理新的配置文件（我至少希望 pacman 知道新包中的配置文件何时版本与安装的版本不同，因为它在新版本中发生了更改或者因为我在本地修改了它）。
包签名（似乎正在从事）。
对于 arch 来说，唯一真正的原因是它默认安装的软件包很少，并且鼓励您添加所需的软件包，因此默认情况下不安装可选依赖项可能会促使用户安装以避免膨胀。
答案2
我从 Ubuntu lucid 开始了我的 Linux 之旅，目前使用 Arch。我已经编写了一些 Arch 软件包，我会说它比编写 Debian 软件包容易得多。但是，我想指出的是@绅士恶魔Arch 确实有一个用于包的钩子系统，称为install file.
基本上，它的名称是${pkgname}.install，并包含一些用于安装前/安装后/删除/升级的功能；只需将您的字体缓存更新放入其中即可，它的工作原理与 Debian hook 几乎相同。
另外，我注意到您提到使用 debian 包管理工具“固定”应用程序； Arch 的 pacman 也具有内置功能，/etc/pacman.conf接受许多设置，包括IgnorePkg =，这将阻止升级到等号（空格分隔）之后列出的任何软件包
答案3
在我走得太远之前，先研究一下Linux 时间线图解
要了解包管理器的差异，您必须了解上图所示操作系统的原理
三大父母
- Redhat，现在 Fedora - Package Manger - RPM，Redhat Package Manager 的缩写，命令行
rpm - Slackware - 包管理器 - tgz，普通压缩文件。虽然这些只是压缩文件，但它们是由 Slackware 上游构建的，并放置在存储库中，有时称为端口
- Debian - DEB，Debian 的缩写，它的命令行工具是
Aptitude or Apt
这些父母是我们今天所知的大多数发行版的父母。包管理系统的想法/概念是以某种形式或方式衍生或共享的。无论如何，所有这些父母都是二进制分发者，这意味着程序由第三方打包和决定，然后存储在存储库中，并由用户群使用或安装。
3 未成年父母
- Linux From Scratch - 基于源代码，无包管理器。
- Gentoo - 源自从零开始的 Linux。这个发行版本质上是 Linux from Scratch 加上一个包管理器，称为 Portage/emerge
- SourceMage - 魔法包管理器
这些父母是次要的，因为他们的用户群以速度和安装的简易性为代价，以强大的功能和配置的简易性为代价。每个包都是使用变量和配置文件从头开始下载和编译的。
桥
Arch 是作为二进制发行版（如 3 个主要父项之一）和基于源的发行版（如 3 个次要父项之一）之间的桥梁而创建的。因此，它在时间线中接收作为父级的状态，因为没有其他父级提供此功能。 Pacman 可以灵活地允许用户从官方存储库安装二进制包，或使用 Arch 构建系统安装自定义构建的包。这一概念在未成年父母提供的权力与主要父母提供的安装便利性之间提供了平衡。
在我看来，并不是包管理器显示了系统的强大功能，因为所有包管理器都执行相同的任务，即管理和维护健康的系统。因此，您使用的系统应由以下因素决定：
- 用户级别：刚接触 Linux 的人应该从主要父母开始，而技术熟练的人会找到平衡点。
- 您想要对系统做什么：运行带有附加用户的 LAMP 服务器与运行用于网页浏览和电子邮件阅读的台式 PC 完全不同。
- 舒适度：无论用户级别如何，如果您技术熟练，但不想花周末编译系统，您将选择一个主要父级，无论您认识的每个人是否选择其他东西。
答案4
这绝不是一个完整或详尽的答案 - 我面前的海报已经给出了一些非常好的观点，我只想补充我的 2 美分。另一件事 - 我从来没有真正习惯 apt/dpkg。对我来说，它总是显得过于复杂，我真的对 yum/rpm 最满意。
pacman 非常容易使用，这是优点也是缺点 - 你可以在一个下午学会使用它（除了包构建） - 它主要使用直观和完整的包管理功能，但是 - 这是一个很大的但是 -它非常不灵活。
如果设计师事先没有想到某个功能，那你就完蛋了。
举几个例子： pacman 中没有本机版本控制。如果您希望降级软件包版本 - 您必须下载该特定软件包版本，并使用 -U（升级）选项从文件安装。它非常适合在您的系统上始终使用最先进的软件包。
没有真正的内部缓存清理/完全重建。如果（由于网络问题）软件包下载损坏，例如在 -Syu 期间，错误消息虽然准确，但没有多大用处 - 即使打开“完整”详细信息和调试，它也不会查明损坏的软件包，并且无论多少 -Syyc 都不会真正清理缓存并重新下载软件包。好消息是 -Sc 会让您知道下载的软件包在哪里，这样您就可以简单地删除有问题的软件包（如果您能找出是哪一个）或全部软件包，然后重新启动 -Syu。
pacman 与 dkms 的集成也存在一些问题 - 在安装新内核时，我一直遇到来自 dkms 的错误。使用 dkms build && dkms install 针对新内核工作顺利，但 pacman 不会提供任何信息，说明 dkms 在内核升级过程中失败的原因（我怀疑它从未通过新内核的正确路径，只是让 dkms 使用默认路径） （当前运行的）内核但版本错误）。
另一个关于它缺乏灵活性的轶事 - 如前所述，我习惯了 rpm/yum。如果我的系统上有一个文件，并且我想知道哪个包拥有它，我可以运行 yum Provides /path/to/file 并获取可以将其放在那里的所有包 - 即使它们都没有安装。如果文件是手动放置的，现在我想安装一个软件包 - 它会重命名新的软件包（添加扩展名 .rpmnew），并让我选择要使用的软件包。
pacman 只是错误地指出文件已存在，但带有完全不相关的错误消息 - 它抱怨文件“真实”所有者和当前安装的“文件系统”包之间存在冲突，就好像它也是同一文件的所有者一样。此外，它主要面向本地安装的信息 - 尝试获取尚未安装的软件包的信息（例如文件列表和所有权）不太直观。
简单地说 - 它不像 yum 那样成熟，可能还不如 dpkg 成熟，这也导致了它的易用性以及相对不灵活性。