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

数週間から定期的にarchを使用していますそして、このテーマの専門家ではないので、この答えは決して網羅的ではありません。「柔軟性/パワー」について私が指摘したいくつかのポイント：

• これは単なる印象ですが、 pacmanは、そのデザイン/アーキテクチャがよりモダンでシンプルに見えます。少なくとも、対処するツールははるかに少ないです。私はaptソースコードを知りませんが、libalpmコード（pacmanの基盤となるライブラリ）をたまたま見て、非常に単純なパッチを作成しました。それはクリーンで理解しやすいようです。

• これも非常に高速です（最適化のため、またおそらくいくつかのことを気にすることによって（以下を参照））。最後のリリース（pacman 3.5、数日前）は、数を減らすことによってパフォーマンスを改善しようとしました。関係するデータベースファイル。

• archはバイナリパッケージの使用を目的としていますが、BSDのポートと同様のビルドシステムを使用して、ソースからパッケージをビルドする場合にも利点があります（ ABS）。

• パッケージの作成は非常に簡単で迅速です。PKGBUILDファイルに数行を追加するだけで完了します。コントロール/ルール/著作権を処理する必要はありません。 / changelog / Debianパッケージと同じように。そして、Web uiを数回クリックするだけで、パッケージはAUR（Arch User Repository）の全員と共有されます。

私が得たものアーチではなくDebianで：

• Triggers / h ooks（aptがアイコンキャッシュやmandbなどを更新する理由は、パッケージがファイルをインストールする場所を確認するだけで、パッケージャーは何もする必要がない）（があるようです。 これを実装する計画）。

• debconf（大したことではありませんが、手動で行うように強制することで、正確に何が行われているのかを知ることができます）新しい構成ファイルの適切な処理（少なくとも、新しいバージョンで変更されたため、またはローカルで変更したために、新しいパッケージバージョンの構成ファイルがインストールされたものと異なる場合はpacmanに知らせてください）。

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

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

コメント

• これを解析できません’：しかし、それなしで実行できます。ちなみに、自分が何を上手く行っているかを知っています。最後の文にもタイプミスがあります。
• pacmanパッケージマネージャーはどの言語で書かれていますか？ dpkg / aptと同様の低レベルおよび高レベルのパッケージ管理機能がありますか？ある場合、それらは何と呼ばれますか？
• @Tshepang：申し訳ありませんが、英語を母国語としない人はここにいます。 “これは、この機能（debconf）がなくても大したことではなく、手動で行うように強制することで、正確に何が行われているのかを知る必要があります”。
• @Faheem Mitha：PacmanはCで記述されており、”高さの両方を処理するlibalpmのフロントエンドです。 -level “および”低レベル”パッケージ管理。
• @zanko：私は’ネイティブスピーカーでもありません。私があなたにしてほしいのは、コメントではなく、投稿自体に文章を明確にすることだけです。ところで、私が言及したタイプミスはオプションです。自分で投稿を編集することもできますが、説明の部分と一緒に修正したほうがいいと思いました。

Linuxの旅はUbuntulucidから始め、現在はArchを使用しています。私はいくつかのArchパッケージを作成しましたが、Debianパッケージを作成するよりもはるかに簡単です。しかし、 @gentledevil には、Archにはinstall file。

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

また、debianパッケージ管理ツールを使用してアプリケーションを「固定」するとおっしゃっていましたが、Archのpacmanにはそれが組み込まれています。また、/etc/pacman.confは、IgnorePkg =を含む多くの設定を受け入れます。これにより、等しい（スペースで区切られた）の後にリストされているパッケージへのアップグレードが防止されます。 ）

コメント

• また、リポジトリパッケージではありませんが、powerpillラッパーを使用できます。 pacmanが複数のパッケージを並行してダウンロードするため、pacman -S libfoo libbar libbazの代わりに、各パッケージを次々にダウンロードします。 r代わりに、3つすべてを同時にダウンロードし、アップグレード速度を大幅に向上させて接続を改善します。

前に行き過ぎて、ピクトリアルLinuxタイムライン

パッケージマネージャーの違いを理解するには、OSの哲学を理解する必要があります。 “上の写真

3つの主要な親

1. Redhat、現在はFedora-パッケージマネージャー-RPM、Redhat Package Managerの略、コマンドラインrpm
2. Slackware-パッケージマネージャー-tgz、通常のzipファイル。これらは単なる圧縮ファイルですが、Slackwareのアップストリームによって構築され、リポジトリに配置され、ポートと呼ばれることもあります。
3. Debian-DEB、Debianの略で、コマンドラインツールはAptitude or Apt

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

3マイナーな親

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

これらの親は、ユーザーベースがマイナーであるためマイナーです。スピードとインストールの容易さをパワーと構成の容易さと引き換えに。各パッケージは、変数と構成ファイルを使用して、最初からダウンロードおよびコンパイルされます。

ブリッジ

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

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

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

コメント

• これはもっと焦点ですpacmanとDebian ‘のパッケージ管理ツールの比較ではなく、ディストリビューションの系譜を使用しました…
• @jasonwryan That ‘は、すべてのパッケージマネージャーが同じタスクを実行するためです。つまり、emerge packagenameはsudo apt-get install packagenameと同じです。
• そのレベルでは、そうです。しかし、それは質問の要点、つまりpacmanと{apt、aptitude}の違いを完全に見逃しています。
• @jasonwryanブリッジのセクションで答えました。それ以外は違いはありません。唯一の違いはセマンティックです。つまり、あるコマンドと別のコマンドです。OPがセマンティックの違いを探している場合は、そのためのマニュアルがあります。

これは完全または網羅的な答えを意味するわけではありません-私の前のポスターはすでにいくつかの非常に良い点を与えました、私はちょうど私の2セントを追加したいと思います。別のこと-私はapt / dpkgに実際に慣れたことはありません。それは常に過度に複雑に見えました私、私はyum / rpmで本当に最も快適です。

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

設計者が事前に機能について考えていなかった場合、あなたは「困惑します。」 p>

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

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

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

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

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

簡単に言えば、yumほど成熟していません。おそらくdpkgは、使いやすさにも比較的柔軟性がありません。

コメント

• 包括的な非回答の短い、あなたが提起する多くのポイントがありますが、それは本当にpacmanに不慣れなことの産物です。たとえば、pacman -Qo $fileは、どのパッケージが$ fileを所有しているかを示します。また、OPがArchと Debian の違いを明示的に求めたのであなたの答え全体はストローマンです-yumはそれとは何の関係もありません…
• そのため、回答の冒頭でその事実を明示的に開示しました。 -Qo $ fileについては、まだインストールされていないパッケージで試したことはありますか？
• インストールされていないパッケージで試しても意味がありません。そのための他のツールがあります。そして、開示は’あなたが’質問に答えていないという事実を軽減しません：” comparison “は、Debian ‘とArchの違いと同じではありません ‘のパッケージマネージャー。
• @jasonwryanもちろんポイントがあります。 ‘まだインストールされていなくても、ファイルを所有している可能性のあるパッケージを特定する必要がないという理由だけで、’ ‘そのようなニーズが存在しないことを意味します’。それがポイントでした。他のツールに関しては-それらは基礎を知る必要がありますか？ pacmanはパッケージマネージャーです。あなたの要点について-私は質問を完全に誤解したかもしれませんが、それは軽量のPMとより複雑なPMについてであると思いました。 apt / dpkgは、機能的には少なくともyum / rpmと同じくらい複雑であると思います。
• 私のポイントは、リンゴと梨についての限られた理解を比較することで、リンゴとオレンジの比較に関する質問に答えているということです。そして、はい、あなたは質問を完全に読み間違えました…