第6章 Debian FTP アーカイブ

目次

6.1. Debian ディストリビューションはいくつありますか?
6.2. etch や lenny 等という名前は一体何ですか?
6.2.1. 他にはどんなコード名が過去に使われましたか?
6.2.2. このコード名は何に由来しているのですか?
6.3. 「sid」とは何ですか?
6.4. stable ディレクトリには何がありますか?
6.5. テスト版 (testing) ディストリビューションには何が収録されていますか?
6.5.1. 「テスト版 (testing)」はどういうものですか? どのように「凍結 (freeze)」されますか?
6.6. 不安定版 (unstable) ディストリビューションには何が収録されていますか?
6.7. Debian FTP アーカイブにあるこのディレクトリ群は一体何ですか?
6.8. dists/stable/main 以下にあるディレクトリは一体何ですか?
6.9. ソースコードはどこにありますか?
6.10. pool ディレクトリには何がありますか?
6.11. 「incoming」とは何ですか?
6.12. apt 対応リポジトリを用意する方法は?

6.1. Debian ディストリビューションはいくつありますか?

主要なディストリビューションは3つあります:「安定版 (stable)」ディストリビューション、「テスト版 (testing)」ディストリビューション、「不安定版 (unstable)」ディストリビューション。「テスト版 (testing)」ディストリビューションは「凍結」されていることもあります (「「テスト版 (testing)」はどういうものですか? どのように「凍結 (freeze)」されますか?」 参照)。次に、「旧安定版 (oldstable)」ディストリビューション (これは単純に前の「安定版 (stable)」です) と「experimental」ディストリビューションがあります。

Experimental は未だ開発中のパッケージが利用するもので、システムを破壊するような高い危険性があります。これは最前線のソフトウェアについて学習やテストを望む開発者により利用されます。経験のあるほとんどの人にとっても危険で有害である可能性があるため、ユーザがここからパッケージを使うべきではありません。

Debian ディストリビューションを選択する際の手助けについては 3章Debian ディストリビューションの選択 を見てください。

6.2. etch や lenny 等という名前は一体何ですか?

単なる「コード名」です。Debian ディストリビューションが開発段階にあるとき、そこにバージョン番号はなくコード名はあります。このコード名の目的は Debian ディストリビューションのミラー作業を楽にすることです (もし実際のディレクトリ、例えば unstable が突然 stable に変わったとしたら無用に多く再ダウンロードする羽目になるでしょう)。

現在 stablebuster (つまり Debian GNU/Linux 10) へのシンボリックリンクで、testingbullseye へのシンボリックリンクです。これはつまり buster は現在の安定版 (stable) ディストリビューションで、bullseyeは現在のテスト版 (testing) ディストリビューションだということです。

unstable は恒久的に sid へのシンボリックリンクで sid は常に不安定版 (unstable) ディストリビューションです (「「sid」とは何ですか?」 参照)。

6.2.1. 他にはどんなコード名が過去に使われましたか?

Aside buster and bullseye, other codenames that have been already used are: buzz for release 1.1, rex for release 1.2, bo for releases 1.3.x, hamm for release 2.0, slink for release 2.1, potato for release 2.2, woody for release 3.0, sarge for release 3.1, etch for release 4.0, lenny for release 5.0, squeeze for release 6.0, wheezy for release 7, jessie for release 8, stretch for release 9.

6.2.2. このコード名は何に由来しているのですか?

これまでのところ Pixar による映画「トイストーリー」のキャラクターから選ばれています。

  • buzz (Debian 1.1) was the spaceman Buzz Lightyear,

  • rex (Debian 1.2) was the tyrannosaurus,

  • bo (Debian 1.3) was Bo Peep, the girl who took care of the sheep,

  • hamm (Debian 2.0) was the piggy bank,

  • slink (Debian 2.1) was Slinky Dog, the toy dog,

  • potato (Debian 2.2) was, of course, Mr. Potato,

  • woody (Debian 3.0) was the cowboy,

  • sarge (Debian 3.1) was the sergeant of the Green Plastic Army Men,

  • etch (Debian 4.0) was the toy whiteboard (Etch-a-Sketch),

  • lenny (Debian 5.0) was the toy binoculars,

  • squeeze (Debian 6) was the name of the three-eyed aliens,

  • wheezy (Debian 7) was the rubber toy penguin with a red bow tie,

  • jessie (Debian 8) was the yodeling cowgirl,

  • stretch (Debian 9) was the rubber toy octopus with suckers on her eight long arms.

  • buster (Debian 10) was Andy's pet dog.

  • bullseye (Debian 11) was Woody's wooden toyhorse.

  • bookworm (Debian 12) was a green toy worm with a built-in flashlight who loves reading books.

  • sid はおもちゃを全て壊す隣の悪ガキでした。

トイストーリーの名前の使用は、当時 Debian プロジェクトリーダーであり映画制作会社の Pixar で働いていた Bruce Perens により決定されました

6.3. 「sid」とは何ですか?

sid あるいは unstable というのはほとんどのパッケージが最初にアップロードされる場所です。リリースするパッケージは stable にリリースする前にまず testing に収録される必要があるため、これが直接リリースされることはありません。sid にはリリースされるアーキテクチャもリリースされないアーキテクチャも、両方のパッケージが収録されます。

「sid」という名もアニメ映画の「トイストーリー」から来ています: Sid はおもちゃを壊す隣の少年でした :-)

[2]

6.4. stable ディレクトリには何がありますか?

  • stable/main/: このディレクトリには Debian GNU/Linux システムの最新リリースを正式に構成するパッケージが収録されています。

    ここに置かれるパッケージは全て Debian フリーソフトウェアガイドライン (DFSG) に準拠し、全て自由に利用、配布できます。

  • stable/non-free/: このディレクトリには配布に制限があり、指定されている著作権要求について配布者が注意を払う必要のあるパッケージが収録されています。

    例えばパッケージによっては商用での配布を禁止するライセンスを採用しています。他に、再配布はできるものの実際はフリーソフトウェアではなくシェアウェアであるものもあります。こういったパッケージは、(例えば CD-ROM に) 収録して再配布する前に各パッケージごとのライセンスを調査し、場合によっては交渉する必要があります。

  • stable/contrib/: このディレクトリには、それ自体は DFSG フリーで自由に配布できるけれども、自由に配布できないために non-free でのみ利用可能なパッケージに依存しているパッケージが収録されています。

6.5. テスト版 (testing) ディストリビューションには何が収録されていますか?

パッケージは unstable である程度のテストを経た後に「testing」にディレクトリに入ります。

ビルドしている全アーキテクチャで同調していなければならず、インストールできなくなるような依存を作ることもできません。リリースクリティカルバグが現在不安定版 (unstable) にあるバージョンよりも増えることも許されません。こうして、「テスト版 (testing)」が常にリリース候補に近づいていくことを期待します。

「テスト版 (testing)」の状態全般や個々のパッケージについてのさらなる情報は https://www.debian.org/devel/testing にあります。

6.5.1. 「テスト版 (testing)」はどういうものですか? どのように「凍結 (freeze)」されますか?

「テスト版 (testing)」ディストリビューションが十分完成の域に達すると、リリース管理者が「凍結 (freeze)」を開始します。新しいバグが「不安定版 (unstable)」から「テスト版 (testing)」にできるだけ持ち込まれないようにするため、通常の伝搬の遅延は増加します。

しばらくして「テスト版 (testing)」ディストリビューションが本当に「凍結 (freeze)」されます。これは新しいパッケージの「テスト版 (testing)」への伝搬が、それがリリースクリティカルバグを修正するものでない限り全て止められるということです。リリースが迫っているような時には、いわゆる「テストサイクル」の間「テスト版 (testing)」ディストリビューションがこういったさらに強い凍結 (deep freeze) のままになることもあります。

「テスト版 (testing)」リリースが「凍結」されると「不安定版 (unstable)」も同様に部分的な凍結 (freeze) になる傾向があります。これはテスト版 (testing) で凍結 (freeze) されているソフトウェアに些細な更新やテスト版 (testing) が「安定版 (stable)」になるのを妨害するリリースクリティカルバグの修正が必要な場合に、開発者が全く新しいソフトウェアを不安定版 (unstable) にアップロードすることに消極的なためです。

リリースを避ける可能性のあるパッケージやリリース全体を止める可能性のあるバグについて、テスト版 (testing) ディストリビューションのバグ記録を維持しています。詳細についてはテスト版 (testing) リリース情報を見てください。

このバグの数が受け入れられる最大値まで下がると、凍結 (freeze) されているテスト版 (testing) ディストリビューションは安定版 (stable) と宣言され、バージョン番号を付けてリリースされます。

最も重要なバグの数は「リリースクリティカル (RC、Release Critical)」バグの数で、これは Release-critical bug status (RCバグ状況) のページで追うことができます。一般的なリリース目標は NoRCBugs (RCバグ0) で、そのディストリビューションには重要度が critical (致命的)、grave (重大)、serious (深刻) のバグがあるべきではないことを意味します。致命的だと見なされる問題の完全な一覧は RC ポリシー文書にあります。

新しいリリースごとに、以前の安定版 (stable) ディストリビューションは古くなってアーカイブに移動します。さらなる情報については Debian アーカイブを見てください。

6.6. 不安定版 (unstable) ディストリビューションには何が収録されていますか?

「unstable」ディレクトリには現在の開発用システムのスナップショットが収録されます。ここにあるパッケージをユーザが使ってテストするのは歓迎ですが、注意して準備しておく必要があります。不安定版 (unstable) ディストリビューションには常に GNU/Linux ソフトウェアの世界で最新版を使用するという利点がありますが、それが壊れていたとしたら (略)。利点だけではなく欠点もあり得るということです :-)

「unstable」にも「stable」と同一の基準で分けられた main、contrib、non-free サブディレクトリがあります。

6.7. Debian FTP アーカイブにあるこのディレクトリ群は一体何ですか?

Debian GNU/Linux 用にパッケージ化されているソフトウェアは各 Debian ミラーサイトにある複数のディレクトリツリーのどれかから利用できます。

dists ディレクトリは「distributions (ディストリビューション)」の短縮形で現在利用可能な Debian リリース (とリリース前) にアクセスするための正当な手段です。

pool ディレクトリには実際のパッケージが収録されます。pool ディレクトリには何がありますか?」 参照。

以下の補足するディレクトリがあります:

/tools/:

起動ディスクの作成やディスクドライブのパーティション作業、ファイルの圧縮/伸張、Linux のブート等を行う DOS ユーティリティ。

/doc/:

この FAQ やバグ報告システムの説明等、基礎的な Debian 文書。

/indices/:

サイトの様々な索引 (Maintainers ファイルや override ファイル)。

/project/:

ほぼ開発者だけを対象とするものや雑多なファイル。

6.8. dists/stable/main 以下にあるディレクトリは一体何ですか?

Within each of the major directory trees[3], there are three sets of subdirectories containing index files.

利用可能な各コンピュータアーキテクチャ、例えば Intel x86 PC マシン上で実行するパッケージ向けの binary-i386 や Sun SPARCStation 上で実行するパッケージ向けの binary-sparc のバイナリパッケージの索引ファイルを収録する binary-何かサブディレクトリ群があります。

各リリースで利用可能なアーキテクチャ完全な一覧はリリースウェブページにあります。現在のリリースについては 「Debian GNU/Linux はどのハードウェアアーキテクチャ/システムで動作しますか?」 を見てください。

binary-* にある索引ファイルは Packages(.gz、.bz2) と呼ばれ、ディストリビューションに収録されている各バイナリパッケージについてのまとめが収録されています。実際のバイナリパッケージは最上位の pool ディレクトリ以下にあります。

さらに source/ というサブディレクトリにはディストリビューションに収録されているソースパッケージの索引ファイルが収録されています。この索引ファイルは Sources(.gz、.bz2) と呼ばれます。

大事なことを言い忘れましたが、インストールシステムの索引ファイル用のサブディレクトリ群が debian-installer/binary-アーキテクチャにあります。

6.9. ソースコードはどこにありますか?

Debian システム全てのソースコードが収録されています。また、このシステムにあるほとんどのプログラムのライセンス条件がソースコードをプログラムと共に配布するかソースコードをプログラムと同時に提供することを要求しています

ソースコードは pool ディレクトリ (pool ディレクトリには何がありますか?」 参照) 以下のアーキテクチャごとの全バイナリディレクトリで一緒に配布しています。FTP アーカイブの構造をよく理解せずにソースコードを取得するには、apt-get source パッケージ名のようにコマンドを使ってみてください。

ライセンスによる制限のため、「contrib」や「non-free」ディレクトリに置かれるパッケージにはソースコードが利用できないものもあり、そういったパッケージは正式には Debian システムの一部ではありません。一部にはソースのない「バイナリ形式」だけが配布可能 (例えば firmware-misc-nonfree) なものやライセンスがビルド済みバイナリの配布を禁止していて、ユーザによりローカルでコンパイルできるソースコードのパッケージの配布は許可しているものがあります (例えば broadcom-sta-dkms)。

6.10. pool ディレクトリには何がありますか?

パッケージは巨大な「pool」に置かれています。ここはソースパッケージの名前を基に構造化されています。管理しやすくするため、pool は区分 (「main」、「contrib」、「non-free」) とソースパッケージ名の頭文字によりさらに分割されています。このディレクトリには複数のファイルが収録されます: 各アーキテクチャ用のバイナリパッケージとそのバイナリパッケージを生成する元となるソースパッケージです。

apt-cache showsrc パッケージ名のようなコマンドを実行してその「Directory:」行を確認することで各パッケージが置かれている場所を調べることができます。例えば apache パッケージは pool/main/a/apache/ に置かれています。

さらに、lib* パッケージはあまりに多いため特別に扱っています: 例えば libpaper パッケージは pool/main/libp/libpaper/ に置かれています。

[4]

6.11. 「incoming」とは何ですか?

開発者がパッケージをアップロードした後、それが本物であることが確認されるまでの短期間「incoming」ディレクトリに置かれ、それからアーカイブ行きが許可されます。

通常この場所からは誰も何かをインストールすべきではありません。しかし、緊急時のまれな状況では https://incoming.debian.org/ にある incoming ディレクトリを利用することができます。手作業によりパッケージを取得して .changes や .dsc ファイルにある GPG 署名や MD5sums を確認しインストールしてください。

6.12. apt 対応リポジトリを用意する方法は?

私的な Debian パッケージをいくらか作成し、標準の Debian パッケージ管理ツールを使ってインストールしたい場合、自分の独自の apt 対応パッケージアーカイブを用意することできます。これは Debian プロジェクトにより配布されるのではない Debian パッケージを共有したい場合にも有用です。その手順は Debian Wiki で示されています。



[2] When the present-day sid did not exist, the FTP site organization had one major flaw: there was an assumption that when an architecture is created in the current unstable, it will be released when that distribution becomes the new stable. For many architectures that isn't the case, with the result that those directories had to be moved at release time. This was impractical because the move would chew up lots of bandwidth.

The archive administrators worked around this problem for several years by placing binaries for unreleased architectures in a special directory called "sid". For those architectures not yet released, the first time they were released there was a link from the current stable to sid, and from then on they were created inside the unstable tree as normal. This layout was somewhat confusing to users.

With the advent of package pools (see pool ディレクトリには何がありますか?」), binary packages began to be stored in a canonical location in the pool, regardless of the distribution, so releasing a distribution no longer causes large bandwidth consumption on the mirrors (there is, however, a lot of gradual bandwidth consumption throughout the development process).

[3] dists/stable/main, dists/stable/contrib, dists/stable/non-free, and dists/unstable/main/, etc.

[4] Historically, packages were kept in the subdirectory of dists corresponding to which distribution contained them. This turned out to cause various problems, such as large bandwidth consumption on mirrors when major changes were made. This was fixed with the introduction of the package pool.

The dists directories are still used for the index files used by programs like apt.