公式リポジトリ
関連記事
ソフトウェアリポジトリとはソフトウェアパッケージの保管場所であり、インストールの際はここからパッケージが取得されます。
Arch Linux の公式リポジトリには重要で人気のあるソフトウェアがあり、pacman ですぐにアクセスできます。これらのリポジトリはパッケージメンテナ達によってメンテナンスされています。
公式リポジトリ内のパッケージは絶えずアップグレードされます: パッケージがアップグレードされると、古いバージョンはリポジトリから削除されます。Arch にはメジャーリリースというものはありません: それぞれのパッケージは、上流のソースで新しいバージョンが利用可能になると、アップグレードされます。各リポジトリは常に一貫性が保たれています。つまり、リポジトリ内のパッケージは、常に他のパッケージと互換性のあるバージョンであるということです。
目次
安定版リポジトリ
core
このリポジトリはミラー上の .../core/os/ にあります。
core には以下のようなパッケージが含まれます:
- Arch Linux の起動に必要なパッケージ。
- インターネットの接続に必要なパッケージ。
- パッケージのビルドに必要なパッケージ。
- サポートされているファイルシステムの管理・修復に必要なパッケージ。
- システムのセットアップに必要なパッケージ (例: openssh)。
他にも、上記パッケージが依存しているパッケージ (必ずしも makedepends ではない) や base メタパッケージも含まれています。
core には、かなり厳しい品質要件が課されています。開発者/ユーザたちは、パッケージの更新が受理される前に、更新を承認する必要があります。使用頻度の低いパッケージの場合は、次のような適切な方法を取れば十分です: 対象パッケージのメンテナの暗黙の承認と共に、人々に更新について通知する、承認を要求する、変更の重大度に応じて core-testing に1週間留める、目立ったバグレポートが無い。
extra
このリポジトリはミラー上の .../extra/os/ にあります。
extra には、core に当てはまらない全てのパッケージが含まれています。 このリポジトリは、Package Maintainers と Arch の開発者によって共同でメンテナンスされています。 パッケージ例: Xorg、ウィンドウマネージャ、ウェブブラウザ、メディアプレイヤ、Python、Ruby などの言語で作業するためのツール。
multilib
このリポジトリはミラー上の .../multilib/os/ にあります。
multilib には、64 ビット環境で 32 ビットアプリケーションを実行したりビルドしたりするために使用できるソフトウェアとライブラリが含まれています (wine、steam など)。
multilib リポジトリを有効化すると、32 ビット互換のライブラリは /usr/lib32/ 下に配置されます。
multilib を有効化する
multilib リポジトリを有効化するには、/etc/pacman.conf 内の [multilib] セクションをアンコメントしてください:
/etc/pacman.conf
[multilib] Include = /etc/pacman.d/mirrorlist
そして、システムをアップグレードし、好きな multilib パッケージをインストールしてください。
multilib を無効化する
multilib からインストールしたパッケージをすべて取り除くには、以下のコマンドを実行してください:
# pacman -R $(comm -12 <(pacman -Qq | sort) <(pacman -Slq multilib | sort))
gcc-lib と衝突が発生する場合、base-devel パッケージの依存パッケージと gcc-libs パッケージを再インストールしてください (Pacman ヒント#パッケージの依存パッケージ を参照)。
/etc/pacman.conf 内の [multilib] セクションをコメントアウトしてください:
/etc/pacman.conf
#[multilib] #Include = /etc/pacman.d/mirrorlist
そして、システムをアップグレードしてください。
テストリポジトリ
テストリポジトリの用途は、パッケージをメインのリポジトリに入れる前に置いておくための中間的な場所を提供することです。パッケージのメンテナ (及び一般ユーザ) は、これらのテストパッケージにアクセスして、新しいパッケージの統合に問題がないことを確認することができます。パッケージがテストされ、誤りが見つからなければ、そのパッケージをメインのリポジトリに移動することができます。
すべてのパッケージがこのテストプロセスを通らなければならないわけではありません。新しいパッケージがテストリポジトリに入るケースとしては:
- そのパッケージが core リポジトリに入る場合。core 内のすべてのパッケージは core-testing を通らなければなりません。
- そのパッケージをアップデートすると何かを壊してしまうことが予想され、まずテストする必要がある場合。
- そのパッケージが多くのパッケージに影響を与える場合 (perl や python など)。
また、テストリポジトリは GNOME や KDE といった、パッケージの巨大なコレクションの新しいリリースの際にも用いられます。
core-testing
このリポジトリはミラー上の .../core-testing/os/ にあります。
core-testing には、core リポジトリへの候補となるパッケージが含まれています。
core-testing は、他の公式リポジトリと名前の衝突を起こす可能性がある唯一のリポジトリです。有効化するには、このリポジトリを /etc/pacman.conf ファイル内の最初のリポジトリにしなければなりません。
extra-testing
このリポジトリは core-testing リポジトリと似ていますが、extra リポジトリの候補になっているパッケージのために存在しています。
multilib-testing
このリポジトリは core-testing リポジトリと似ていますが、multilib リポジトリの候補になっているパッケージのために存在しています。
gnome-unstable
このリポジトリにはメインの extra-testing リポジトリに入る前の GNOME デスクトップ環境の次期安定板や安定板のリリース候補版が入っています。
有効化するには、以下を /etc/pacman.conf に追加してください:
/etc/pacman.conf
[gnome-unstable] Include = /etc/pacman.d/mirrorlist
gnome-unstable エントリは、設定ファイル内のリポジトリリストの中で最初のリポジトリにする必要があります (つまり、core-testing エントリよりも上)。
パッケージに関するバグは Arch Linux の GitLab に、その他のバグについては上流の GNOME Gitlab に報告してください。
kde-unstable
このリポジトリには KDE Plasma や KDE Applications の最新ベータ版やリリース候補版が入っています。
有効にするには、以下を /etc/pacman.conf に追加してください:
/etc/pacman.conf
[kde-unstable] Include = /etc/pacman.d/mirrorlist
kde-unstable エントリは、設定ファイル内のリポジトリリストの中で最初のリポジトリにする必要があります (つまり、core-testing エントリよりも上)。
何か問題を発見したときはバグレポートを作成してください。
testing リポジトリの無効化
有効にした testing リポジトリを無効化したい場合、以下を実行してください:
/etc/pacman.confからリポジトリを削除 (あるいはコメントアウト)。pacman -Syuuを実行して、リポジトリからのアップデートを"ロールバック"。
二番目のコマンドは必ずしも実行する必要がないこともありますが、何か問題が起きていたら実行してみてください。
ステージングリポジトリ
このリポジトリには壊れたパッケージが含まれており、多数のパッケージを一度にリビルドする間だけ開発者が使います。共有ライブラリが新しくなったときなどの理由で依存パッケージをリビルドするとき、まず最初に共有ライブラリ自体がビルドされるとステージングリポジトリにアップロードされ他の開発者が利用可能になります。全ての依存パッケージがリビルドされた直後 testing か main リポジトリのうち適切なほうに移動されます。
歴史的背景の詳細は、ステージングリポジトリの導入に関するアナウンスを参照。
歴史的背景
リポジトリが分割されていますが、これらの殆どは歴史的な理由によるものです。昔、Arch Linux を利用している人がとても少なかった頃、official (現在の core) と呼ばれるたった一つのリポジトリだけがありました。当時は、official には主として Judd Vinet の好きなアプリケーションが入っていました。プログラムの"タイプ"ごとにそれぞれ一つのプログラムが入っていたのです (一つの DE、 一つのメジャーブラウザ、など)。
ユーザーが Judd の選択したプログラムを好まない時は、簡単に使える Arch build system により、自分たちでパッケージを作っていました。これらのパッケージは unofficial という名のリポジトリに入れられ、Judd 以外の開発者によって管理されていたのです。次第に、その 2 つのリポジトリは開発者によって等しくサポートされるようになり、official と unofficial という名前は実態を表さなくなりました。そこで、リリースバージョン 0.5 あたりで、それらは共に current と extra と名前を変えました。
2007.8.1 リリースのすぐ後、何が含まれているのか混乱することを防ぐために current は core になりました。新旧リポジトリのほとんどは開発者やコミュニティの目からみると今でもあまり変わっていませんが、core は少々異なっています。主な違いは、インストール CD やリリーススナップショットに入っているパッケージだけが core に含まれていたということです。このリポジトリだけでも Linux システムを構築することはできますが、おそらくあなたの求める Linux システムにはなりません。
さて、0.5 や 0.6 の期間に、開発者が管理するには吝か、パッケージが多すぎることが問題になりました。Jason Chu は "Trusted User リポジトリ" を作り、信用されたユーザー (Trusted User) が作ったパッケージを置く非公式リポジトリにしました。staging リポジトリという、公式リポジトリに提案されているパッケージを置くリポジトリがありましたが、それは Arch Linux 開発者によるもので、それ以外の開発者と信用されたユーザーは多かれ少なかれ異なっていたのが理由です。
信用されたユーザーが彼らのリポジトリに飽き、信用されてないユーザー (Untrusted User) が彼らのパッケージを共有したいと思う前になされたこの作業は、AUR の開発として引き継がれました。TU たちは結集して、より強固なグループを作り、community リポジトリを集団で管理するようになりました。信用されたユーザーたちは未だに Arch Linux の開発者とは分裂していましたが、開発者との間ですくなからず連絡を取り合っていました。しかし、時には community から extra に人気のあるパッケージを移動するように求めることもありました。また、すべてのユーザーは AUR を使って PKGBUILD を投稿することができます。
core に入ったカーネルが多くのユーザーのシステムを破壊する事件がおこった後、"core 承認ポリシー" (core signoff policy) が導入されました。その時から、core にある全てのパッケージはアップデートの際にまず core-testing を通過しなくてはならなくなり、Arch テストチームの他の開発者や人々から複数の承認が得られて初めて core への移動が許されるようになりました。それも時間がたつにつれ、いくつかの core パッケージがあまり使われなくなったので、そのようなパッケージはユーザーの承認やバグレポートが少ないという基準で運用されています。
2009年末から2010年初頭にかけて、新しいファイルシステムの出現とそれらのサポートの要望ために、core は明確には定義されなくなった (たんに"開発者によって選ばれた重要なパッケージ"が入っている) 実情にあわせて、リポジトリにはより正確な説明が付けらました。
2021 年から "Trusted Users" が "Package Maintainers" に改名され始め、2023 年末に完全に改名されました。
2023年、数年の準備作業を経て、ディストリビューションのバックエンドサービスを git に移行し、それと同時に新しいリポジトリレイアウトに切り替わりました。新しいレイアウトでは、以前 community にあったパッケージがすべて extra へ移動され、テストリポジトリが testing から core-testing と extra-testing に分かれ、community-testing は完全に削除されました。この時点から、Package Maintainers は新しいパッケージを extra にプッシュすることもできるようになりました。