DebianとArchのパッケージ管理の違い

この投稿からの議論は、DebianとArchのパッケージ管理の違いに興味をそそられました。また、Archは非常に軽量であるとよく言われるので、パッケージ管理とはどういう関係があるのでしょうか。DebianがデフォルトでRecommendsをハードな依存関係として扱っているためでしょうか？

また、2つのパッケージマネージャー間の柔軟性/能力についても説明できますか？

Archは単一のスイートとDebianが複数のスイートを持っているため（たとえば、APTのピン留めと高度な依存関係の処理が頭に浮かぶ）、Debianパッケージ管理システムで利用可能ないくつかの機能はArchシステムでは無関係であることを認識しています。両方のシステムに適用できます（つまり、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（大したことではなく、手動で行うことを強制することで、私は正確に何が行われたかを知ることを強いられます）と新しい構成ファイルの適切な処理新しいバージョンで変更されたか、ローカルで変更したため、インストールされているバージョンとは異なります）。

• パッケージ署名（作業中のようです）。

archが軽い場合の唯一の本当の理由は、デフォルトでインストールされるパッケージがほとんどないため、必要なものだけを追加することをお勧めします。したがって、デフォルトでオプションの依存関係をインストールしないことは、ユーザーに膨張を回避してインストールするように促すことです。

私はLinuxの旅をUbuntu lucidから始め、現在はArchを使用しています。少数のArchパッケージを作成しましたが、Debianパッケージを作成するよりもはるかに簡単です。ただし、@ gentledevilには、Archにはと呼ばれるパッケージ用のフックシステムがあることを指摘しておきますinstall file。

基本的に、その名前が付けられ${pkgname}.installており、インストール前/インストール後/削除/アップグレード用のいくつかの関数が含まれています。フォントキャッシュの更新をその中に配置するだけで、Debianフックとほぼ同じように機能します。

また、debianパッケージ管理ツールを使用してアプリケーションを「固定」することについて言及したことにお気づきでしょうか。Archのパックマンにもその組み込み/etc/pacman.conf機能があり、等を含むIgnorePkg =（スペース区切り）の後にリストされているパッケージへのアップグレードを防止するを含む、いくつかの設定を受け入れます。

行き過ぎる前に、Pictorial Linux Timelineを調べてください。

パッケージマネージャーの違いを理解するには、上記のOSの考え方を理解する必要があります

三大親

1. Redhat、Now Fedora-Package Manger-RPM、Redhat Package Managerの略、コマンドライン rpm
2. Slackware-Package Manager-tgz、通常の圧縮ファイル。これらは単なる圧縮ファイルですが、Slackwareの上流で作成され、ポートと呼ばれることもあるリポジトリに配置されています。
3. Debian-DEB、Debianの略で、コマンドラインツールは Aptitude or Apt

これらの親は、私たちが今日知っているほとんどのディストリビューションの母親と父親です。パッケージ管理システムのアイデア/コンセプトは、何らかの形または方法で派生または共有されました。いずれにせよ、これらの親はすべてバイナリディストリビュータです。つまり、プログラムはサードパーティによってパッケージ化および決定され、リポジトリに格納され、ユーザーベースによって消費またはインストールされます。

3未成年者の保護者

1. Linux From Scratch-ソースベース、パッケージマネージャーなし。
2. Gentoo- Linux from Scratchから派生。このディストリビューションは、本質的にはScratchのLinuxと、Portage / emergeと呼ばれるパッケージマネージャーです。
3. SourceMage-パッケージマネージャーソーサリー

これらの親はマイナーです。彼らのユーザーベースは、速度とインストールの容易さ、そしてパワーと設定の容易さをトレードオフにしているからです。各パッケージは、変数と構成ファイルを使用して、最初からダウンロードおよびコンパイルされます。

橋

Archは、3つのメジャーな親の1つなどのバイナリディストリビューションと3つのマイナーな親の1つなどのソースベースのディストリビューション間のブリッジとして作成されました。そのため、他の親がこの機能を提供していないため、タイムラインで親としてのステータスを受け取ります。Pacmanには、ユーザーが公式リポジトリからバイナリパッケージをインストールできる柔軟性、またはArch Build Systemを使用してカスタムビルドパッケージをインストールできる柔軟性があります。この概念は、未成年の親が提供する能力と主要な親が提供するインストールの容易さのバランスを提供します。

私の意見では、すべてのパッケージマネージャーが同じタスクを実行するので、システムの能力を示すのはパッケージマネージャーではありません。そのため、使用するシステムは次のような要因によって決定される必要があります。

• ユーザーレベル：Linuxを初めて使用する人は、メジャーペアレントから始める必要がありますが、技術的に熟練した人はバランスを見つけることができます。
• システムで実行したいこと：ユーザーを接続してLAMPサーバーを実行することは、Webブラウジングや電子メールの読み取りのためにデスクトップPCを実行することとはまったく異なります。
• 快適レベル：技術的には熟練しているが、週末にシステムをコンパイルしたくない場合は、ユーザーレベルが耐えられない場合、知っている全員が別のものを選択しているかどうかに関係なく、主要な親を選択します。

これは完全なまたは完全な答えではありません。私の前のポスターはすでにいくつかの非常に良い点を示していたので、2セント追加したいと思います。別のこと-私はapt / dpkgに慣れていません。それはいつも私には複雑すぎるように見えました、私はyum / rpmで本当に最も快適です。

pacmanは非常に使いやすく、長所と短所です。1日の午後にそれを使用する方法（パッケージのビルドは別）を学ぶことができます。ほとんどの場合、直感的で完全なパッケージ管理機能を使用しますが、これは重要ですが-それは非常に柔軟性がありません。

設計者が事前に機能について考えていなかった場合、あなたはうんざりしています。

いくつかの例：pacmanにはネイティブのバージョン管理はありません。パッケージバージョンをダウングレードする場合は、その特定のパッケージバージョンをダウンロードし、-U（アップグレード）オプションを使用してファイルからインストールする必要があります。それはあなたのシステムで常に最先端のパッケージを使用することに向けられています。

実際の内部キャッシュクリーニング/完全な再構築はありません。（ネットワークの問題により）パッケージのダウンロードが破損した場合（例：-Syu）、エラーメッセージは正確ではありますが、あまり役に立ちません-「完全な」冗長性とデバッグがオンになっていても、破損したパッケージを特定できません。 、および-Syycの量は実際にはキャッシュを消去せず、パッケージを再ダウンロードしません。良い知らせは、-Scはダウンロードされたパッケージの場所を通知するので、問題のあるパッケージ（どれかがわかる場合）またはすべてを削除して、-Syuを再起動できます。

pacmanとdkmsの統合もやや問題があります-新しいカーネルをインストールしている間、dkmsでエラーが発生し続けました。新しいカーネルに対してdkms build && dkms installを使用すると問題なく機能しましたが、pacmanは、カーネルのアップグレード中にdkmsが失敗した理由をまったく提供しません（新しいカーネルの正しいパスを通過せず、dkmsにデフォルトを使用させるだけだと思います） （現在実行中）カーネルですが、バージョンが正しくありません）。

それについてのもう一つの逸話は柔軟性がない-述べたように、私はrpm / yumに慣れています。システムにファイルがあり、どのパッケージがそれを所有しているのかを知りたい場合は、yumprovides / path / to / fileを実行して、そこに配置できるすべてのパッケージを取得できます。ファイルが手動で配置され、パッケージをインストールしたい場合-新しいファイルの名前を変更し（拡張子.rpmnewを追加）、使用するものを選択します。

pacmanは単にファイルがすでに存在することをエラーで表示しますが、まったく関係のないエラーメッセージが表示されます。ファイル「true」の所有者と現在インストールされている「filesystems」パッケージが同じファイルの所有者であるかのように競合します。また、主にローカルにインストールされた情報を対象としています。まだインストールされていないパッケージの情報（ファイルリストや所有権など）を取得しようとすると、直感性が低下します。

簡単に言えば、それはyumほど成熟しておらず、おそらくdpkgです。これは、使いやすさも兼ね備えており、比較的柔軟性に欠けます。