公式リポジトリ

関連記事

• Arch build system
• Arch User Repository
• makepkg
• ミラー
• 公式リポジトリウェブインターフェイス
• pacman
• PKGBUILD
• 非公式ユーザーリポジトリ

ソフトウェアリポジトリとはソフトウェアパッケージの保管場所であり、インストールの際はここからパッケージが取得されます。

Arch Linux の公式リポジトリには重要で人気のあるソフトウェアがあり、pacman ですぐにアクセスできます。これらのリポジトリはパッケージメンテナ達によってメンテナンスされています。

公式リポジトリ内のパッケージは絶えずアップグレードされます: パッケージがアップグレードされると、古いバージョンはリポジトリから削除されます。Arch にはメジャーリリースというものはありません: それぞれのパッケージは、上流のソースで新しいバージョンが利用可能になると、アップグレードされます。各リポジトリは常に一貫性が保たれています。つまり、リポジトリ内のパッケージは、常に他のパッケージと互換性のあるバージョンであるということです。

安定版リポジトリ

core

このリポジトリはミラー上の .../core/os/ にあります。

core には以下のようなパッケージが含まれます:

• Arch Linux の起動に必要なパッケージ。
• インターネットの接続に必要なパッケージ。
• パッケージのビルドに必要なパッケージ。
• サポートされているファイルシステムの管理・修復に必要なパッケージ。
• システムのセットアップに必要なパッケージ (例: openssh)。

他にも、上記パッケージが依存しているパッケージ (必ずしも makedepends ではない) や base メタパッケージも含まれています。

core には、かなり厳しい品質要件が課されています。開発者/ユーザたちは、パッケージの更新が受理される前に、更新を承認する必要があります。使用頻度の低いパッケージの場合は、次のような適切な方法を取れば十分です: 対象パッケージのメンテナの暗黙の承認と共に、人々に更新について通知する、承認を要求する、変更の重大度に応じて core-testing に1週間留める、目立ったバグレポートが無い。

ヒント: インターネット接続無しで core (或いは他のリポジトリ) のパッケージを含むローカルリポジトリを作成するには、Pacman ヒント#パッケージを CD/DVD や USB スティックからインストールする を見てください。

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 リポジトリ内のパッケージをすべて一覧表示するには、pacman -Sl multilib を実行してください。32 ビットライブラリのパッケージ名は lib32- で始まります。

multilib を無効化する

multilib からインストールしたパッケージをすべて取り除くには、以下のコマンドを実行してください:

# pacman -R $(comm -12 <(pacman -Qq | sort) <(pacman -Slq multilib | sort))

gcc-lib と衝突が発生する場合、base-devel パッケージの依存パッケージと gcc-libs パッケージを再インストールしてください (Pacman ヒント#パッケージの依存パッケージ を参照)。

ノート: 先のコマンドが error: no targets specified (use -h for help) (エラー: 対象が指定されていません (-h を使ってヘルプを見て下さい)) と出力した場合、multilib リポジトリのパッケージはシステムにインストールされていないことを意味します。

/etc/pacman.conf 内の [multilib] セクションをコメントアウトしてください:

/etc/pacman.conf

#[multilib]
#Include = /etc/pacman.d/mirrorlist

そして、システムをアップグレードしてください。

テストリポジトリ

テストリポジトリの用途は、パッケージをメインのリポジトリに入れる前に置いておくための中間的な場所を提供することです。パッケージのメンテナ (及び一般ユーザ) は、これらのテストパッケージにアクセスして、新しいパッケージの統合に問題がないことを確認することができます。パッケージがテストされ、誤りが見つからなければ、そのパッケージをメインのリポジトリに移動することができます。

すべてのパッケージがこのテストプロセスを通らなければならないわけではありません。新しいパッケージがテストリポジトリに入るケースとしては:

• そのパッケージが core リポジトリに入る場合。core 内のすべてのパッケージは core-testing を通らなければなりません。
• そのパッケージをアップデートすると何かを壊してしまうことが予想され、まずテストする必要がある場合。
• そのパッケージが多くのパッケージに影響を与える場合 (perl や python など)。

また、テストリポジトリは GNOME や KDE といった、パッケージの巨大なコレクションの新しいリリースの際にも用いられます。

ノート: テストリポジトリは、最も新しいパッケージを保管するためにあるのではありません。このリポジトリの目的の1つは、core パッケージ群の一部であったり別な方法で重要であったりするという理由でシステムを壊してしまう可能性があるパッケージのアップデートを保留することです。なので、テストリポジトリのユーザは、arch-dev-public メーリングリストを購読すること、テストリポジトリのフォーラムを読むこと、すべてのバグを報告することが強く推奨されています。また、Arch テストチームへの参加も考慮すべきです。

警告:

• テストリポジトリには、リリース前のソフトウェアバージョンが含まれている場合があります。
• テストリポジトリを有効にするときは気をつけて下さい。アップデート後にシステムが壊れる可能性があります。潜在的なシステムの故障の対処方法を知っている、経験のあるユーザーだけがこのリポジトリを使うべきです。
• core-testing を有効にするときは、extra-testing も一緒に有効にする必要があります。逆も然りです。また、以下のサブセクションに書かれている他のテストリポジトリを有効にする場合も、core-testing と extra-testing の両方も有効にしなければなりません。
• メインリポジトリ内にあるパッケージでもテストリポジトリ内には存在しないこともあるので、メインリポジトリである core と extra も保持しておく必要があります。また、これらのリポジトリに対応するテストリポジトリは、メインリポジトリよりも前に指定する必要があります。

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 リポジトリを無効化したい場合、以下を実行してください:

1. /etc/pacman.conf からリポジトリを削除 (あるいはコメントアウト)。
2. pacman -Syuu を実行して、リポジトリからのアップデートを"ロールバック"。

二番目のコマンドは必ずしも実行する必要がないこともありますが、何か問題が起きていたら実行してみてください。

ステージングリポジトリ

警告: staging リポジトリはどのような理由でも有効化してはいけません。アップデート後にシステムが間違いなく破壊されます。バックエンドの開発者のみが使用することを意図しています。

このリポジトリには壊れたパッケージが含まれており、多数のパッケージを一度にリビルドする間だけ開発者が使います。共有ライブラリが新しくなったときなどの理由で依存パッケージをリビルドするとき、まず最初に共有ライブラリ自体がビルドされるとステージングリポジトリにアップロードされ他の開発者が利用可能になります。全ての依存パッケージがリビルドされた直後 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 にプッシュすることもできるようになりました。

翻訳ステータス: このページは en:Official repositories の翻訳バージョンです。最後の翻訳日は 2024-02-04 です。もし英語版に 変更 があれば、翻訳の同期を手伝うことができます。