「公式リポジトリ」の版間の差分
(→community-testing: 削除) |
(→テスト中リポジトリ: 同期) |
||
87行目: | 87行目: | ||
そして、システムを[[アップグレード]]してください。 |
そして、システムを[[アップグレード]]してください。 |
||
− | == テスト |
+ | == テストリポジトリ == |
+ | テストリポジトリの用途は、パッケージをメインのリポジトリに入れる前に置いておくための中間的な場所を提供することです。パッケージのメンテナ (及び一般ユーザ) は、これらのテストパッケージにアクセスして、新しいパッケージの統合に問題がないことを確認することができます。パッケージがテストされ、誤りが見つからなければ、そのパッケージをメインのリポジトリに移動することができます。 |
||
− | === testing === |
||
+ | すべてのパッケージがこのテストプロセスを通らなければならないわけではありません。新しいパッケージがテストリポジトリに入るケースとしては: |
||
− | {{Warning|[testing] リポジトリを有効にするときは気をつけて下さい。アップデート後にシステムが壊れる可能性があります。潜在的なシステムの故障の対処方法を知っている、経験のあるユーザーだけがこのリポジトリを使うべきです。}} |
||
− | + | * そのパッケージが ''core'' リポジトリに入る場合。''core'' 内のすべてのパッケージは ''core-testing'' を通らなければなりません。 |
|
+ | * そのパッケージをアップデートすると何かを壊してしまうことが予想され、まずテストする必要がある場合。 |
||
+ | * そのパッケージが多くのパッケージに影響を与える場合 ({{Pkg|perl}} や {{Pkg|python}} など)。 |
||
+ | また、テストリポジトリは [[GNOME]] や [[KDE]] といった、パッケージの巨大なコレクションの新しいリリースの際にも用いられます。 |
||
− | [core] や [extra] リポジトリに入る候補のパッケージを含む特別なリポジトリです。 |
||
+ | {{Note|1=テストリポジトリは、最も新しいパッケージを保管するためにあるのではありません。このリポジトリの目的の1つは、''core'' パッケージ群の一部であったり別な方法で重要であったりするという理由でシステムを壊してしまう可能性があるパッケージのアップデートを保留することです。なので、テストリポジトリのユーザは、[https://lists.archlinux.org/mailman3/lists/arch-dev-public.lists.archlinux.org/ arch-dev-public メーリングリスト]を購読すること、[https://bbs.archlinux.org/viewforum.php?id=49 テストリポジトリのフォーラム]を読むこと、[[バグ報告ガイドライン|すべてのバグを報告する]]ことが強く推奨されています。また、[[Arch テストチーム]]への参加も考慮すべきです。}} |
||
− | 次の場合に新しいパッケージが [testing] に入ります: |
||
+ | {{Warning| |
||
− | * アップデート時に何か問題が起こる可能性があり、テストが必要な場合。 |
||
+ | * テストリポジトリを有効にするときは気をつけて下さい。アップデート後にシステムが壊れる可能性があります。潜在的なシステムの故障の対処方法を知っている、経験のあるユーザーだけがこのリポジトリを使うべきです。 |
||
+ | * ''core-testing'' を有効にするときは、''extra-testing'' も一緒に有効にする必要があります。逆も然りです。また、以下のサブセクションに書かれている他のテストリポジトリを有効にする場合も、''core-testing'' と ''extra-testing'' の両方も有効にしなければなりません。 |
||
+ | }} |
||
+ | === core-testing === |
||
− | * 他のパッケージのリビルドを必要としている場合。この場合、リビルドが必要な全てのパッケージが [testing] に入れられ、全てのリビルドが完了してから、他のリポジトリに移されます。 |
||
− | + | このリポジトリはミラー上の {{ic|.../core-testing/os/}} にあります。 |
|
+ | ''core-testing'' には、''core'' リポジトリへの候補となるパッケージが含まれています。 |
||
− | {{Note|[testing] は "一番新しい"パッケージバージョンがあるとは限りません。このリポジトリの目的は、[core] に入ると'''システム破壊を引き起こす'''恐れのあるパッケージアップデートを保持することです。なので、[testing] リポジトリのユーザーは [https://lists.archlinux.org/listinfo/arch-dev-public arch-dev-public] メーリングリストを講読すること、[https://bbs.archlinux.org/viewforum.php?id=49 <nowiki>[testing]</nowiki> リポジトリフォーラム] を読むこと、バグを全て[[バグ報告ガイドライン|報告]]することを'''強く推奨'''されています。[[Arch テストチーム]] への参加も考慮してください。}} |
||
− | + | ''core-testing'' は、他の公式リポジトリと名前の衝突を起こす可能性がある唯一のリポジトリです。有効化するには、このリポジトリを {{ic|/etc/pacman.conf}} ファイル内の最初のリポジトリにしなければなりません。 |
|
+ | |||
+ | === extra-testing === |
||
+ | |||
+ | このリポジトリは ''core-testing'' リポジトリと似ていますが、''extra'' リポジトリの候補になっているパッケージのために存在しています。 |
||
=== multilib-testing === |
=== multilib-testing === |
||
− | このリポジトリは |
+ | このリポジトリは ''core-testing'' リポジトリと似ていますが、''multilib'' リポジトリの候補になっているパッケージのために存在しています。 |
=== gnome-unstable === |
=== gnome-unstable === |
||
− | このリポジトリにはメインの |
+ | このリポジトリにはメインの ''extra-testing'' リポジトリに入る前の [[GNOME]] デスクトップ環境の次期安定板や安定板のリリース候補版が入っています。 |
− | + | 有効化するには、以下を {{ic|/etc/pacman.conf}} に追加してください: |
|
+ | {{hc|/etc/pacman.conf|2= |
||
− | [gnome-unstable] |
||
+ | [gnome-unstable] |
||
− | Include = /etc/pacman.d/mirrorlist |
||
+ | Include = /etc/pacman.d/mirrorlist |
||
+ | }} |
||
+ | ''gnome-unstable'' エントリは、設定ファイル内のリポジトリリストの中で最初のリポジトリにする必要があります (つまり、''extra-testing'' エントリよりも上)。 |
||
− | パッケージに関連するバグは Arch Linux の[https://bugs.archlinux.org/ バグトラッカー] に、その他のバグについては上流の [https://gitlab.gnome.org GNOME Gitlab] に報告してください。 |
||
+ | |||
+ | パッケージに関連するバグは Arch Linux の[https://bugs.archlinux.org/ バグトラッカー]に、その他のバグについては上流の [https://gitlab.gnome.org GNOME Gitlab] に報告してください。 |
||
=== kde-unstable === |
=== kde-unstable === |
||
− | このリポジトリには [[KDE]] Plasma や Applications の最新ベータ版 |
+ | このリポジトリには [[KDE]] Plasma や KDE Applications の最新''ベータ''版や''リリース候補版''が入っています。 |
+ | |||
+ | 有効にするには、以下を {{ic|/etc/pacman.conf}} に追加してください: |
||
+ | {{hc|/etc/pacman.conf|2= |
||
− | [kde-unstable] を有効にするには、以下の行を {{ic|/etc/pacman.conf}} に追加してください。''kde-unstable'' エントリは一番上 (''testing'' エントリよりも上) に記述する必要があります: |
||
+ | [kde-unstable] |
||
+ | Include = /etc/pacman.d/mirrorlist |
||
+ | }} |
||
+ | ''kde-unstable'' エントリは、設定ファイル内のリポジトリリストの中で最初のリポジトリにする必要があります (つまり、''extra-testing'' エントリよりも上)。 |
||
− | [kde-unstable] |
||
− | Include = /etc/pacman.d/mirrorlist |
||
何か問題を発見したときは[[バグ報告ガイドライン|バグレポートを作成]]してください。 |
何か問題を発見したときは[[バグ報告ガイドライン|バグレポートを作成]]してください。 |
||
139行目: | 156行目: | ||
有効にした testing リポジトリを無効化したい場合、以下を実行してください: |
有効にした testing リポジトリを無効化したい場合、以下を実行してください: |
||
− | # {{ic|/etc/pacman.conf}} からリポジトリを削除 |
+ | # {{ic|/etc/pacman.conf}} からリポジトリを削除 (あるいはコメントアウト)。 |
− | # {{ic|pacman -Syuu}} を実行して、リポジトリからのアップデートをロールバック。 |
+ | # {{ic|pacman -Syuu}} を実行して、リポジトリからのアップデートを"ロールバック"。 |
二番目のコマンドは必ずしも実行する必要がないこともありますが、何か問題が起きていたら実行してみてください。 |
二番目のコマンドは必ずしも実行する必要がないこともありますが、何か問題が起きていたら実行してみてください。 |
2023年5月25日 (木) 02:08時点における版
ソフトウェアリポジトリとは、コンピュータに取得・インストールされるパッケージを置いておくストレージのことです。Arch Linux のパッケージメンテナ (開発者と Trusted User) は重要な・人気のあるソフトウェアパッケージが入った公式リポジトリを管理しています。この記事では公式にサポートされているリポジトリについて説明します。
目次
安定版リポジトリ
core
このリポジトリはミラー上の .../core/os/
にあります。
core には以下のようなパッケージが含まれます:
- Arch Linux の起動に必要なパッケージ。
- インターネットの接続に必要なパッケージ。
- パッケージのビルドに必要なパッケージ。
- サポートされているファイルシステムの管理・修復に必要なパッケージ。
- システムのセットアップに必要なパッケージ (例: openssh)。
他にも、上記パッケージが依存しているパッケージ (必ずしも makedepends ではない) や base メタパッケージも含まれています。
core には、かなり厳しい品質要件が課されています。開発者/ユーザたちは、パッケージの更新が受理される前に、更新を承認する必要があります。使用頻度の低いパッケージの場合は、次のような適切な方法を取れば十分です: 対象パッケージのメンテナの暗黙の承認と共に、人々に更新について通知する、承認を要求する、変更の重大度に応じて core-testing に1周間留める、目立ったバグレポートが無い。
extra
このリポジトリはミラー上の .../extra/os/
にあります。
extra には、core に当てはまらない全てのパッケージが含まれています。 このリポジトリは、Trusted Users と 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 エントリは、設定ファイル内のリポジトリリストの中で最初のリポジトリにする必要があります (つまり、extra-testing エントリよりも上)。
パッケージに関連するバグは Arch Linux のバグトラッカーに、その他のバグについては上流の GNOME Gitlab に報告してください。
kde-unstable
このリポジトリには KDE Plasma や KDE Applications の最新ベータ版やリリース候補版が入っています。
有効にするには、以下を /etc/pacman.conf
に追加してください:
/etc/pacman.conf
[kde-unstable] Include = /etc/pacman.d/mirrorlist
kde-unstable エントリは、設定ファイル内のリポジトリリストの中で最初のリポジトリにする必要があります (つまり、extra-testing エントリよりも上)。
何か問題を発見したときはバグレポートを作成してください。
testing リポジトリの無効化
有効にした testing リポジトリを無効化したい場合、以下を実行してください:
/etc/pacman.conf
からリポジトリを削除 (あるいはコメントアウト)。pacman -Syuu
を実行して、リポジトリからのアップデートを"ロールバック"。
二番目のコマンドは必ずしも実行する必要がないこともありますが、何か問題が起きていたら実行してみてください。
ステージングリポジトリ
このリポジトリには壊れたパッケージが含まれており、多数のパッケージを一度にリビルドする間だけ開発者が使います。共有ライブラリが新しくなったときなどの理由で依存パッケージをリビルドするとき、 まず最初に共有ライブラリ自体がビルドされるとステージングリポジトリにアップロードされ他の開発者が利用可能になります。全ての依存パッケージがリビルドされた直後 testing か main リポジトリのうち適切なほうに移動されます。
歴史的背景の詳細は [1] を参照。
歴史的背景
リポジトリが仕分けされていることには歴史的な理由があります。昔、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 の期間に、開発者が管理するには吝か、パッケージが多すぎることが問題になりました。開発者のひとり (Xentac) は "Trusted User リポジトリ" を作り、信用されたユーザー (Trusted User) が作ったパッケージを置く非公式リポジトリにしました。[staging] リポジトリという、公式リポジトリに提案されているパッケージを置くリポジトリがありましたが、それは Arch Linux 開発者によるもので、それ以外の開発者と信用されたユーザーは多かれ少なかれ異なっていたのが理由です。
信用されたユーザーが彼らのリポジトリに飽き、信用されてないユーザー (Untrusted User) が彼らのパッケージを共有したいと思う前になされたこの作業は、AUR の開発として引き継がれました。TU たちは結集して、より強固なグループを作り、今では [community] リポジトリを集団で管理するようになりました。信用されたユーザーたちは未だに Arch Linux の開発者とは分裂していますが、開発者との間ですくなからず連絡をとりあっています。時には [community] から [extra] に人気のあるパッケージを移動するように求めることもあります。また、信用されてないユーザーは AUR を使って PKGBUILD を投稿することができます。
[core] に入ったカーネルが多くのユーザーのシステムを破壊する事件 がおこった後、"core 承認ポリシー" (core signoff policy) が導入されました。その時から、[core] にある全てのパッケージはアップデートの際にまず [testing] を通過しなくてはならなくなり、他の開発者から多くの承認が得られて初めて [core] への移動が許されるようになりました。それも時間がたつにつれ、いくつかの [core] パッケージがあまり使われなくなったので、そのようなパッケージはユーザーの承認やバグレポートが少ないという基準で運用されています。
2009年末から2010年初頭にかけて、新しいファイルシステムの出現とそれらのサポートのために、[core] は明確には定義されなくなった(たんに"開発者によって選ばれた重要なパッケージ"が入っている)実情にあわせて、リポジトリにはより正確な説明が付けられています(以下を参照)。