Arch Linux またはその派生ディストリビューション (EndeavourOS、Manjaro、Artix など) を使用している場合、遅かれ早かれ、 AURリポジトリと有名なyayおよびparuアシスタント誰もがそれらについて語り、フォーラムで推奨され、ほとんどすべてのガイドに登場するが、どれを使うべきか決めようとすると、その違いは必ずしも明確ではない。
以下の文章では、それぞれのサービスが何を提供しているのか、コミュニティの実際の意見はどのようなものか、そしてそれらを取り巻く神話はどのようなものなのかを冷静に分析していきます。 「イェイは死んだ」または「パルの方がずっと速い」そして、どのような場合に一方から他方へ切り替える価値があるのかについても解説します。最終的には、考えすぎずにアシスタントを選ぶための確固たる根拠が得られるようになることを目指しています。
yayとparuとは何ですか？また、なぜみんなそれらを使うのですか？
大まかに言えば、yayとparuはどちらも パッケージの検索、コンパイル、インストール作業を自動化するAURアシスタント AUR からパッケージを取得するだけでなく、舞台裏では pacman を使用して公式リポジトリからパッケージを管理します。つまり、手動で AUR Web サイトにアクセスして PKGBUILD をダウンロードし、実行する代わりに、 makepkg そしてパッケージをインストールする。彼らはそれらすべてを一度に行う。
Arch Linux および派生環境では、 AURには膨大な数のソフトウェアカタログが用意されています。そこには、公式リポジトリにないアプリケーション、Git バージョン、実験的なパッチ、あるいは公式にパッケージ化されていないプログラムなどが見つかります。たとえば、 Arch LinuxにVisual Studio Codeをインストールするそれらすべてをある程度簡単に管理するために、ほとんどの人はアシスタントを利用することになり、その中でもyayとparuは最も人気のある選択肢の2つとして挙げられます。
Yayは長年にわたり、業界をリードするブランドの一つとして知られています。 それはよく知られており、記録も残されており、巨大なコミュニティが存在する。 そして、EndeavourOSのようなディストリビューションではデフォルトで搭載されています。一方、Paruは比較的新しいツールですが、AURワークフローに対してより厳格で安全なアプローチを提供していること、そして開発者が過去にyayの開発に関わっていたことから、大きな注目を集めています。
技術的な違い：GoとRust、設計と哲学
議論の中で必ずと言っていいほど出てくる点の一つは、 yayはGo言語で書かれており、paruはRust言語で書かれている。技術的には、これは時折言われるほどエンドユーザーにとって重要ではないが、各プロジェクトのアプローチについて何かを物語っていると言えるだろう。
Go言語で開発されたYayは、次のような古いアシスタントに触発されています。 ヤウルト、アパックマン、パカウルGo言語に精通している人であれば、そのコードは比較的読みやすく拡張しやすい。そして、その歴史的な美点の1つはまさにそこにある。 コンパイルは迅速かつ簡単です。その基盤があったからこそ、開発チームの変更後も存続し続けることができたのだ。
一方、ParuはRustで実装されており、機能面とコマンドラインインターフェース設計の両面でyayの経験を直接取り入れています。そのため、 yayからparuへの移行は非常に簡単です多くのコマンドやオプションはほとんど同じように感じられるので、すべてを最初から覚え直す必要はありません。
哲学的レベルでは、パルはやや重点を置いている PKGBUILDのセキュリティとレビューyayはこれまで、デフォルトでより高速で便利なワークフローを優先する傾向がありました。この違いは、パッケージを作成する前にファイルを表示する方法に明確に表れています。
スピード：パルは本当にイェイより速いのか？
フォーラムやソーシャルネットワークで最もよく繰り返される議論の1つは、 paruはyayよりも「速い」この点を明確にしておく価値があります。高性能なハードウェアと良好な接続環境（例えば、1Gbpsの光ファイバー）を持つ複数のユーザーが、実際には、 両者のスピード感は非常に似ているこのようなシステムでは、ボトルネックとなるのはウィザードではなく、ソフトウェア自体のダウンロードやコンパイルであることが多い。
それでも、より控えめなマシンで両者を比較し、 Paruは特定の操作をやや高速に実行するこれは、公式リポジトリとAURの両方を含む検索、同期、またはグローバルアップデートを実行する際に特に顕著です。通常、その差はそれほど大きくありませんが、リソースが限られているシステムやディスク速度が遅いシステムでは、数秒程度の改善が見られる場合があります。
コインの裏側は paruはデフォルトでコンパイル前にPKGBUILDをチェックするように強制しますこれは、当然ながら（わずかではあるが）人間の時間を消費する対話型の手順を追加することになる。一部のユーザーはこれを「処理速度の低下」と捉える一方、セキュリティと透明性を確保するための妥当な妥協策だと考えるユーザーもいる。
つまり、最新のコンピューターと良好なインターネット接続があれば、 yayとparuの速度差は非常に小さいでしょうParuを選ぶことが本当に価値のある場面は、一秒たりとも無駄にできないような限られたシステム環境、あるいは細部に至るまで最適化されたアシスタントを求めていて、そのわずかな利点に気づく場合でしょう。
構文とユーザーエクスペリエンス：タイピングの感覚
ベンチマークや技術的な議論を超えて、多くのユーザーが「やった！」と喜ぶ理由は、実にありふれたものだ。 書くのはとても快適です短いし覚えやすいし、ターミナルでオートコンプリートされるから、文字通り「両方のキーを同時に押して」yayと入力する人もいる、と言う人もいる。
パルはひどい名前というわけではないが、 彼らの構文は、彼らにとっては少し「粗雑」に思える 毎日使っている場合、コマンド自体はそれほど大きく異なるわけではありませんが、習慣が勝り、yayを長年使っている人は、思考プロセスと入力作業の両方において、より自然で速いワークフローだと感じます。
いずれにしても、両方のアシスタントは ショートカット、インタラクティブなオプション、非常によく似たフラグ例えば、リポジトリとAURの更新をバージョン詳細とともに表示する統合メニューなどの機能は、どちらにも備わっています。yayには、 --combinedupgradeこれは、更新される内容と更新前のバージョンを色分けしたリストで表示します。Paruでは、同様の機能はオプションで実現できます。 --upgrademenu詳細なアップデートメニューを提供しています。
いくつかのスレッドで見られる興味深い詳細の1つは、 次のようなエイリアスを作成するユーザーもいます yaya わーいなぜなら、そのように呼び出す方がより便利で楽しいと感じるからだ。これは、アシスタントを選ぶ際に人間工学と習慣が非常に重要な役割を果たしていることを明確に示している。
コンパイルされた各パッケージはどこに保存されますか？
見過ごされがちなもう一つの興味深い側面は、 事前にビルドされたパッケージ（.pkg.tar.zst ファイル）ここで、yayとparuは若干異なる動作をするため、それらが一般的なArchパスとどのように統合されるかに影響します。
デフォルトでは、 makepkgはビルドされたパッケージをビルドディレクトリに配置します。そのルートは変数を使用して調整できます PKGDEST en /etc/makepkg.conf例えば、次のように送信できます。 /var/cache/pacman/pkg/ パッケージ化されたバイナリを一元管理するため。
paruの場合、makepkgの通常の動作に従います。 パッケージは最終的に paru に関連付けられたコンパイル ディレクトリに配置されます。通常は次のようなもの ~/.cache/paru/clone/$pkgname/そのパスをグローバルに変更したい場合は、次のオプションを使用できます。 BuildDir en /etc/paru.confコンパイルしたデータを別のサイトに転送する。
Yay は多少異なる動作をします。複数のユーザーが指摘しているように、 やったー、ビルドされたパッケージをコピーして /var/cache/pacman/pkg/ これらをコンパイルすると、AUR パッケージが pacman で管理される公式パッケージと同じ場所に配置されることになります。これは便利ですが、ある意味では「yay は...」ということになります。 あなたが定義したものを踏みつける PKGDEST en /etc/makepkg.confこれは、システム全体の構成に対する敬意を欠く行為だと考える人もいる。
平均的なユーザーにとっては通常大きな問題ではありませんが、マシン上のバイナリの構成方法に非常にこだわる場合は、 これは、パルの「より清潔な」行動を好む理由となるかもしれない。少なくとも、各アシスタントがあなたの荷物に対して何をしているのかを把握しておくべきです。
各プロジェクトの保守レベルと活動状況
さまざまな議論の中で、次のような考えが広まっている。 yayは廃止または時代遅れであり、paruが自然な代替品である。この発言は、yayに関わっていた開発者の1人がparuに専念するためにプロジェクトを離れたという事実が一因となっており、一部の動画や投稿では、これがyayプロジェクトが終焉を迎えた、あるいはメンテナンスされなくなったと解釈された。
複数のユーザーや開発者が、その主張を断固として否定している。 やった、まだメンテナンスが継続されているんだ。リポジトリへのコミットが頻繁に行われ、かなり大きなコミュニティが支えている。実際、一部のメンテナーの不満の一部は、プロジェクトの実際の状態を確認しようともせず、「やった、もう終わった！」という決まり文句が何度も繰り返されるのを目にすることから生じている。
同時に、 パルは非常に高い活動性を示し、その活動は継続的に続いている。場合によっては、特定の状況下では「yay」の評価をわずかに上回ることもあります。これは当然のことです。なぜなら、このプロジェクトは比較的新しく、細部を繰り返し改善していくことに意欲的で、コミュニティからの問題や要望に迅速に対応する熱心な作者がいるからです。
実際には、単にパッケージをインストールしたいだけのユーザーにとって、こうした活動の違いが問題になることはほとんどありません。 どちらのプロジェクトも現在も進行中で、バグ修正や新機能の提供を受けている。そして、短期的には壊れてしまうことを恐れて、yayを諦めざるを得ない理由は何もありません。
セキュリティ、PKGBUILDのレビュー、およびAURの使用に関する考え方
アプローチに明確な違いが見られる重要なポイントの1つは 各参加者がPKGBUILDsのレビューにどのように取り組むかAURは公式リポジトリではないことを覚えておいてください。ここに掲載されているレシピはユーザーによって投稿されたものであり、それらをレビューする最終的な責任はユーザー自身にあります。
Archコミュニティは常に主張してきた PKGBUILDをインストールする前に、必ず内容を確認してください。不快なサプライズ（悪意のあるスクリプト、信頼できないソースからのダウンロード、危険なコマンドなど）を避けるため、Paru はこの理念に基づき、パッケージをビルドする前にこのレビューを表示し、注意を払うよう「強制」するようにデフォルトで設定されています。
やった、PKGBUILDもチェックできるよ、 より速く、より気楽な流れを促進する シンプルな解決策をお望みなら、これは利便性を重視し、AURのメンテナーを信頼するユーザーにとって非常に魅力的ですが、「yay」は「調べずにインストールする」ことを助長するという認識も生み出しており、これはArchの純粋主義的な精神とはあまり合致しません。
いずれにしても、どの補助ツールを使うにしても、 すべてはMakepackとPacmanを経由することになるつまり、どちらも面倒な作業を自動化するのに役立ちますが、基本的なモデルは同じです。PKGBUILD ファイルがパッケージになり、それを pacman が管理してインストールします。インストールする内容を理解する責任は、依然としてユーザー自身にあります。
アシスタントなしでAURを使用し、パックマンの役割を担う
複数のスレッドで繰り返し出てくる質問があります。 「ウィザードを使わずにAURパッケージをアップデートするにはどうすればよいですか？」Archの公式哲学と直接一致する正統的な答えは明確です。 makepkg 対応するPKGBUILDを使用して手動で行います。
PKGBUILDは、定義するレシピです。 ソースコードまたはプリコンパイル済みバイナリからパッケージをビルドする方法パッケージが生成されると、pacman は公式リポジトリのパッケージと同様に、インストールとログ記録を処理します。「AUR」であることによる特別な扱いはなく、pacman にとって、パッケージ化されたパッケージは単なる別のパッケージです。
ヤイやパルのようなアシスタントは 「PKGBUILD をダウンロード → makepkg → pacman」という定番の流れの上に、快適さをさらに高める要素が加わった。これらのツールは、検索を実行したり、依存関係を解決したり、ダウンロードやコンパイルを自動化したり、便利なメニューやオプションを追加したりしますが、中央システムマネージャーとしてのpacmanの役割を置き換えたり変更したりすることはありません。
そのため、一部のベテランユーザーはアシスタントを一切使わないことを自慢し、手動による方法こそが最も透明性が高く、制御しやすいと主張します。一方、大多数のユーザーは時間を節約するために手動ツールに頼ることを好み、自動化によって作業内容を見失うことなく生活が簡素化されると信じています。
Paruとyayは、EndeavorOS、Manjaro、Artixなどの派生ディストリビューションにも搭載されています。
EndeavourOSのようなディストリビューションでは、yayは通常 プリインストールされているか、メインアシスタントとして推奨されていますこれは新規ユーザーの体験に大きな影響を与えます。システムや公式ドキュメントに記載されている通り、彼らは深く考えずに「yay」という表記を採用してしまうからです。その後、「paru」という表記を知り、変更する価値があるかどうかを検討するようになるかもしれません。
EndeavourOSコミュニティ内部での議論の中で、以下の点が提起された。 彼らはParuをデフォルトで含めるようにすべきだ。多くのユーザーやチームメンバーから、yayは依然として堅牢でメンテナンスが行き届いており、広く知られているツールであるため、そうする必要性は特に感じられないとの回答がありました。したがって、短期的および中期的に、このディストリビューションでyayがparuに大規模に置き換えられることはないと思われます。
他のArch派生ディストリビューション（Artix、Manjaroなど）でも状況は同様です。 重要なのは、AURにアクセスできることと、アシスタントを使用できることです。しかし、最終的にどれを使うかは、通常、ドキュメントの推奨事項、コミュニティの意見、あるいは単に最初に試してみてうまくいったものによって決まります。
外部リポジトリの有効化を提案することも一般的です。 カオス-AUR AUR自体からコンパイルすることなくこれらのアシスタントを簡単にインストールできるように、いくつかのチュートリアルでは、システムを準備し、これらのリポジトリを追加し、最初の手動ビルド手順を回避して、yayまたはparuをバイナリパッケージとして直接インストールする方法を説明しています。
両方のアシスタントをインストールして使いこなしましょう。
多くのユーザー、特にテスト中のユーザーに好まれる選択肢の1つは、 yayとparuの両方をインストールしてください。 そして、両方をしばらく使い続けてみてください。こうすることで、普段から行っている作業にはyayを使い、特定の作業にはparuを試用し、自分のハードウェア上で使い心地や機能を比較することができます。
これらのツールはpacmanとmakepkgに依存しているため、 彼らは共存することで互いの邪魔をしたり、システムを破壊したりしない。一方のツールでパッケージをインストールし、もう一方のツールでアップデート一覧を表示するなど、操作方法さえ分かっていれば大きな問題なく作業を続けることができます。好みのツールが明確になったら、操作を簡素化したい場合は、最も気に入ったツールだけを残して、もう一方をアンインストールすれば良いでしょう。
特定のケースでは、インストールすることをお勧めします paruがyayを使用しています （yayはディストリビューションにプリインストールされているので）試してみて、気に入ったらスクリプト、エイリアス、習慣をparuに切り替えて、yayなしで作業してください。ただし、繰り返しますが、 この変更を行う技術的な義務はないそれはむしろ好みと哲学の問題だ。
一方で、常に「バニラ」方式に従うことを好む人もいる。 makepkgを使用してAUR自体からアシスタントをインストールします。純粋でシンプルなArchの哲学との一貫性を保つため。いずれの場合も、最終的な結果は同じです。AURの利用を簡素化する機能的なアシスタントが手に入ります。
これらのニュアンスをすべてまとめて見ると、明らかなのは どちらのアシスタントも、平均的なArchユーザーのニーズを非常によく満たしている。ParuはAURとのやり取りを自動化し、システムを常に最新の状態に保ち、Pacmanが設計上提供していない便利な機能をいくつか備えています。Paruは改訂作業と若干洗練されたパフォーマンスに重点を置いている一方、Yayは非常に馴染みやすく、テンポが速く、確立された体験を提供しており、新しい代替ソフトが登場しても多くの人がYayに忠実であり続ける理由を説明しています。
