Debian和Arch之间的软件包管理差异

这篇文章的讨论使我对Debian和Arch软件包管理之间的差异感到好奇。另外，人们倾向于说Arch非常轻巧，所以我想知道与包管理有什么关系。可能是因为默认情况下Debian将“ 推荐”视为硬依赖吗？

您还可以提及两个软件包管理器之间的灵活性/功能吗？两者中的哪个可以让您做更多的事情。

我知道Debian软件包管理系统上可用的某些功能在Arch系统上是不相关的，因为Arch有一个套件，而Debian有多个（例如，想到了APT固定和高级依赖项处理），所以请比较一下适用于两个系统（即假设对于Debian，我只使用不稳定的）。

从几个星期以来，我只是经常使用arch，因此在这个问题上我不是专家，所以这个答案绝不是详尽无遗的，我只提到了一些关于“灵活性/力量”的要点：

• 这只是一个印象，但是pacman在设计/架构上似乎更现代，更简单。至少要处理的工具要少得多。尽管我不知道apt源代码，但我只是偶然地看了libalpm代码（pacman的基础库）来制作了一个非常简单的补丁，而且看起来很干净而且易于理解。

• 它也非常快（由于优化，而且可能只关心很少的事情（见下文））。最新版本（pacman 3.5，已有几天的历史）试图通过减少所涉及的数据库文件的数量来提高性能。

• 虽然arch面向使用二进制软件包，但在从源构建软件包时也具有优势，其构建系统类似于BSD的端口（ABS）。

• 创建软件包非常简单快捷，只需在PKGBUILD文件中创建几行即可完成，无需处理control / rules / copyright / changelog / Debian软件包。在Web ui上单击几下，您的软件包将与AUR（Arch用户存储库）上的每个人共享。

我在Debian中得到的东西不在arch中：

• 触发器/挂钩（通过查看软件包的安装文件位置，而无需打包程序执行任何操作，可以使apt更新图标缓存，mandb或其他内容）（似乎有计划实现此目的）。

• debconf（没什么大不了的，顺便说一句，强迫我手动执行操作会迫使我知道确切完成了什么）和正确处理新的配置文件（我至少希望pacman知道新软件包中的配置文件何时版本与已安装的版本有所不同，因为它是在新版本中更改的，或者因为我在本地进行了修改）。

• 包签名（似乎正在处理）。

对于轻巧的拱门，唯一的真正原因是默认情况下它很少安装软件包，并且建议您添加所需的软件包，因此默认情况下可能不安装可选依赖项会导致用户安装以避免膨胀。

我从Ubuntu lucid开始了Linux之旅，目前使用Arch。我已经编写了一些Arch软件包，并且说它比编写Debian软件包容易得多。但是，我想向@gentledevil指出，Arch确实具有用于软件包的挂钩系统，称为install file。

基本上，它名为${pkgname}.install，并且包含一些用于安装前/安装后/删除/升级的功能；只需将字体缓存更新放入其中，依此类推，它的工作原理与Debian挂钩几乎相同。

另外，我注意到您提到使用debian软件包管理工具“固定”应用程序。Arch的pacman也具有内置功能，/etc/pacman.conf可以接受许多设置，包括IgnorePkg =，这将阻止升级到等号（以空格分隔）之后列出的任何软件包。

在我走得太远之前，请学习《Pictorial Linux时间轴》

要了解包管理器中的差异，您必须了解上图所示操作系统的理念。

三大父母

1. Redhat，现在Fedora-软件包管理器-RPM，Redhat软件包管理器的缩写，命令行 rpm
2. Slackware-软件包管理器-tgz，普通的压缩文件。尽管这些只是压缩文件，但它们是由Slackware上游构建的，并放置在存储库中，有时也称为端口
3. Debian-DEB，Debian的缩写，它的命令行工具是 Aptitude or Apt

这些父母是我们今天所知道的大多数分布的父母。软件包管理系统的思想/概念是以某种形式或方式派生或共享的。无论如何，所有这些父项都是二进制分发者，这意味着程序由第三方打包和决定，然后存储在存储库中，并由用户库使用或安装。

3个未成年父母

1. Linux From Scratch-基于源，无软件包管理器。
2. Gentoo- 从Scratch衍生自Linux。该发行版实质上是Scratch的Linux，外加一个名为Portage / emerge的软件包管理器。
3. SourceMage-包管理器法术

这些父级是次要的，因为他们的用户群交易速度快，易于安装，功能强大且易于配置。每个软件包都使用变量和配置文件从头开始下载和编译。

桥

Arch是作为二进制分布（例如3个主要父母之一）和基于源的分布（例如3个未成年人父母之一）之间的桥梁而创建的。因此，它在时间轴中以父级状态接收，因为没有其他父级提供此功能。Pacman具有灵活性，允许用户从官方存储库安装二进制程序包，或使用Arch Build System安装自定义程序包。这个概念在未成年人父母给予的力量与主要父母给予的简易安装之间取得了平衡。

在我看来，并不是包管理器显示了系统的功能，因为所有包管理器都执行相同的任务，即管理和维护健康的系统。因此，您所使用的系统应由以下因素决定：

• 用户级别：linux新手应该以“主要父母”作为起点，而精通技术的人会找到一个平衡点。
• 您要对系统执行的操作：运行具有附加用户的LAMP服务器与运行台式机进行Web浏览和电子邮件阅读完全不同。
• 舒适级别：如果您精通技术，但又不想花一个周末来编译系统，则用户级别不高，您将选择一个主要的父级，而不管您认识的每个人是否选择其他方案。

这绝不是一个完整或详尽的答案-我之前的海报已经给出了一些非常好的要点，我只想加2美分。另一件事-我从未真正习惯过apt / dpkg。在我看来，它似乎总是过于复杂，我对yum / rpm非常满意。

pacman非常易于使用，这是一个优点和缺点-您可以在一个下午学习使用它（放在一边打包软件包）-它使用了大多数直观且完整的软件包管理功能，但是-这虽然很大，但是-这是非常不灵活的。

如果设计人员事先没有想到某个功能，那么您就大为困惑。

一些示例：pacman中没有本地版本控制。如果要降级软件包版本，则必须下载该特定的软件包版本，然后使用-U（升级）选项从文件安装。它非常适合始终在系统上使用最先进的软件包。

没有真正的内部缓存清除/完全重建。如果（由于网络问题）软件包下载已损坏，例如，在-Syu期间，错误消息虽然准确无误，但没有多大用处-即使“冗长”的冗长性和调试信息打开，也不会查明损坏的软件包，并且-Syyc数量不会真正清除缓存并重新下载软件包。好消息是-Sc会让您知道下载的软件包在哪里，因此您可以简单地删除有问题的软件包（如果可以找出是哪个软件包）或所有软件包，然后重新启动-Syu。

pacman与dkms的集成也有些问题-在安装新内核时，我一直在dkms中遇到错误。在新内核上使用dkms build && dkms安装可以顺利进行，但是pacman不会提供任何信息，无论为什么dkms在内核升级期间失败（我怀疑它从未通过新内核的正确路径，只是让dkms使用默认值） （当前正在运行）内核，但版本错误。

关于它的灵活性的另一个轶事-如前所述，我习惯于rpm / yum。如果我的系统上有文件，并且我想知道哪个文件包拥有该文件，我可以运行yum提供的/ path / to / file并获取所有可以放置该文件的包-即使没有安装它们。如果文件是手动放置的，现在我希望安装一个软件包-它会重命名新的软件包（添加扩展名.rpmnew），然后让我选择要使用的软件包。

pacman只是错误地指出一个文件已经存在，但是带有一条完全不相关的错误消息-它抱怨文件“ true”所有者与当前安装的“ filesystems”软件包之间的冲突，就好像它也是同一文件的所有者一样。而且，它主要针对本地安装的信息-尝试获取尚未安装的软件包的信息（例如文件列表和所有权）不太直观。

简而言之-它不如yum和dpkg那样成熟，这也使其相对易于使用，这也使其易于使用。