「公式リポジトリ」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
細 (→‎歴史的背景: 修正)
162行目: 162行目:
 
== ステージングリポジトリ ==
  
== ステージングリポジトリ ==
   
−
{{Warning|ステージングリポジトリはどのような理由でも有効化してはいけません。アップデート後にシステムが間違いなく破壊されます。バックエンドの開発者のみが使用することを意図しています。}}
 +
{{Warning|''staging'' リポジトリはどのような理由でも有効化してはいけません。アップデート後にシステムが間違いなく破壊されます。バックエンドの開発者のみが使用することを意図しています。}}
   
−
このリポジトリには壊れたパッケージが含まれており、多数のパッケージを一度にリビルドする間だけ開発者が使います。共有ライブラリが新しくなったときなどの理由で依存パッケージをリビルドするとき、
 +
このリポジトリには壊れたパッケージが含まれており、多数のパッケージを一度にリビルドする間だけ開発者が使います。共有ライブラリが新しくなったときなどの理由で依存パッケージをリビルドするとき、まず最初に共有ライブラリ自体がビルドされるとステージングリポジトリにアップロードされ他の開発者が利用可能になります。全ての依存パッケージがリビルドされた直後 testing か main リポジトリのうち適切なほうに移動されます。
−
まず最初に共有ライブラリ自体がビルドされるとステージングリポジトリにアップロードされ他の開発者が利用可能になります。全ての依存パッケージがリビルドされた直後 testing か main リポジトリのうち適切なほうに移動されます。
  
   
−
歴史的背景の詳細は [https://lists.archlinux.org/pipermail/arch-dev-public/2010-August/017579.html] を参照。
 +
歴史的背景の詳細は、[https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/7RNII5TUKV3BJPGGBYKB7DNUK3WI26GZ/ ステージングリポジトリの導入に関するアナウンス]を参照。
   
 
== 歴史的背景 ==
  
== 歴史的背景 ==

2023年5月25日 (木) 19:20時点における版

関連記事

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

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

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

安定版リポジトリ

core

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

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

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

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

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

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 リポジトリ内のパッケージをすべて一覧表示するには、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 ヒント#パッケージの依存パッケージ を参照)。

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

  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 の期間に、開発者が管理するには吝か、パッケージが多すぎることが問題になりました。開発者のひとり (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] は明確には定義されなくなった（たんに"開発者によって選ばれた重要なパッケージ"が入っている）実情にあわせて、リポジトリにはより正確な説明が付けられています（以下を参照）。

2023年、数年の準備作業を経て、ディストリビューションのバックエンドサービスを git に移行し、それと同時に新しいリポジトリレイアウトに切り替わりました。新しいレイアウトでは、以前 community にあったパッケージがすべて extra へ移動され、テストリポジトリが testing から core-testing と extra-testing に分かれ、community-testing は完全に削除されました。この時点から、Trusted Usersは新しいパッケージを extra にプッシュできるようになりました。

「https://wiki.archlinux.jp/index.php?title=公式リポジトリ&oldid=31795」から取得