DebianとArchのパッケージ管理の違い
この投稿 からの議論で、DebianとArchのパッケージ管理の違いに興味を持ちました。また、Archは非常に軽量だと言われがちなので、パッケージ管理とはどういう関係があるのだろうか。 DebianがRecommendsをデフォルトでハード依存関係として扱っているからかもしれませんか？
また、2つのパッケージマネージャー間の柔軟性/パワーについても言及できますか。2つのうちどちらがより多くのことを可能にします。
Archには単一のスイートがあり、Debianには複数のスイートがあるため、Debianパッケージ管理システムで利用できる一部の機能はArchシステムには関係がないことを認識しています（例：APTピン留めと高度な依存関係の処理覚えておいてください）、両方のシステムに適用できる機能を比較してください（つまり、Debianの場合、unstableのみを使用すると仮定します）。
私は数週間からArchを定期的に使用しており、このテーマの専門家ではないため、この回答は決して網羅的なものではなく、「柔軟性/パワー」について指摘したいくつかのポイントにすぎません。
これは単なる印象ですが、パックマンのデザイン/アーキテクチャはよりモダンでシンプルに見えます。少なくとも、対処するツールははるかに少ないです。 aptのソースコードはわかりませんが、たまたまlibalpmコード（pacmanの基盤となるライブラリ）を見て、非常に単純なパッチを作成しました。これはクリーンで理解しやすいようです。
また、非常に高速です（最適化のため、またおそらくいくつかのことを気にすることによって（以下を参照））。前回のリリース（pacman 3.5、数日前）は、関連するデータベースファイルの数を減らすことで、パフォーマンスを向上させようとしました。
Archはバイナリパッケージの使用を目的としていますが、BSDのポート（ABS）と同様のビルドシステムを使用して、ソースからパッケージをビルドする場合にも利点があります。
パッケージの作成は非常に簡単で迅速で、PKGBUILDファイルに数行で完了します。Debianパッケージのようにcontrol/rules/copyright/changelog /を処理する必要はありません。また、Web UIを数回クリックするだけで、パッケージがAUR（Arch User Repository）の全員と共有されます。
ArchではなくDebianで得られるもの：
トリガー/フック（パッケージャーが何もする必要なしに、パッケージがファイルをインストールする場所を確認するだけで、aptがアイコンキャッシュやmandbなどを更新する理由）（実装する 計画 があるようですこの）。
debconf（大したことではありませんが、手動で行うように強制することで、正確に何が行われているのかを知る必要があります）と新しい構成ファイルの適切な処理（少なくともpacmanに新しいパッケージの構成ファイルがいつあるかを知ってもらいたい）新しいバージョンで変更されたため、またはローカルで変更したため、インストールされているバージョンとは異なります）。
パッケージ署名（それは 作業中 であるようです）。
Archが軽量であるための唯一の本当の理由は、デフォルトでインストールされるパッケージがほとんどなく、必要なものだけを追加することをお勧めすることです。したがって、デフォルトでオプションの依存関係をインストールしないことは、ユーザーに肥大化を回避するように促します。
私はUbuntulucidでLinuxの旅を始め、現在はArchを使用しています。私はいくつかのArchパッケージを作成しましたが、Debianパッケージを作成するよりもはるかに簡単だと思います。しかし、私は @ gentledevil Archにはinstall fileとして知られるパッケージ用のフックシステムがあることを指摘したいと思います。
基本的に、その名前は${pkgname}.installであり、インストール前/インストール後/削除/アップグレード用のいくつかの関数が含まれています。フォントキャッシュの更新をその中に配置するだけで、Debianフックとほぼ同じように機能します。
また、Debianパッケージ管理ツールを使用してアプリケーションを「固定」するとおっしゃっていました。 Archのパックマンにもそれが組み込まれています。/etc/pacman.confはIgnorePkg =を含む多くの設定を受け入れます。これにより、equals（スペース区切り）の後にリストされているパッケージへのアップグレードが防止されます。