[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ 次のページ ]

Debian レファレンス
第 2 章 - Debian の基礎知識


本章は非開発者のために Debian システムの基礎的な情報を供給します。 信頼できる情報が欲しい場合は、次を参照してください:

References, 第 15.1 節 にリストされています。

あまり詳しくない "how-to" 的な説明を探している場合、 Debian パッケージ管理, 第 6 章 や他の該当する章にすぐ飛んでください。

本章は "Debian FAQ" から取られた文書に基づき、通常の Debian システム管理者が始められるように大規模な再構成を行いました。


2.1 Debian アーカイブ


2.1.1 ディレクトリ構造

Debian 用にパッケージングされているソフトウェアは Debian mirror site のそれぞれのいくつかの ディレクトリツリーの一つから FTP 並びに HTTP 経由で取得できます。

次のディレクトリは 各 Debian ミラーサイトの debian ディレクトリの下で見つかります:

dists/:
このディレクトリには "distributions" が含まれており、これは 現在 Debian relaese および pre-release で得られるパッケージへの 標準的なアクセス手段として使用されます。いくつかの古いパッケージや Packages.gz もまだここにあります。
pool/:
ここは Debian release および pre-release の全パッケージ の物理的に存在する場所です。
tools/:
ブートディスク作成、ハードディスクのパーティショニング、 ファイル圧縮/解凍、そして Linux のブート用の DOS ユーティリティが ここにあります。
doc/:
FAQ, バグ報告システム指示書などの基本的な Debian に関する 文書がここにあります。
indices/:
Maintainers ファイルや override ファイルがここにあります。
project/:
主に開発者のみ必要なものです。例えば:
project/experimental/:
本ディレクトリにはまだ開発中であり、まだ α テスト段階の パッケージやツールが含まれます。ユーザはここにあるパッケージを 使用するべきではありません。なぜなら最も経験を積んだひとでさえも 危険で害を及ぼす可能性があるからです。
project/orphaned/:
古いメンテナにより「みなしご化」され、ディストリビューションから なくなったパッケージです。

2.1.2 Debian ディストリビューション

通常 dists ディレクトリには 3種類の Debian ディストリビューションが存在します。これらは stabletesting そして unstable と呼ばれます。 時々 frozen も存在します。各ディストリビューションは dists ディレクトリにある、コードネームが付いた 実際のディレクトリのシンボリックリンクとして定義されています。


2.1.3 stable ディストリビューション

stable ディストリビューション, Debian Woody (3.0r0) 用のパッケージ エントリは stable (woody/ への シンボリックリンク) ディレクトリに記録されています:

現在は、上に挙げた場所に加えて、pool ディレクトリに新しい 物理的なパッケージがあります。 (pool ディレクトリ, 第 2.1.10 節 参照)

stable ディストリビューションの最新バグステータスは Stable Problems web ページに 報告されています。


2.1.4 testing ディストリビューション

testing ディストリビューション、Debian Sarge のパッケージ エントリは unstable でしばらくテストを受けた後に testing (sarge/ への シンボリックリンク) ディレクトリに記録されます。 上に挙げた場所に加え、pool ディレクトリに新しい 物理的なパッケージがあります。 (pool ディレクトリ, 第 2.1.10 節 参照) testing/stable/ と同じ機能を提供する maincontrib そして non-free サブディレクトリもあります。

これらのパッケージはビルドされ、インストール不能なパッケージに依存しない 全アーキテクチャで同期しなくてはなりません。また、unstable にあるバージョンよりも release-critical bug が少なくてはなりません。 このように、testing は常に release candidate 間近であることを 希望しています。testing のメカニズムの詳細については http://ftp-master.debian.org/testing/ にあります。

testing ディストリビューションの最新バグステータスはこれらのサイト で報告されています:


2.1.5 unstable ディストリビューション

unstable ディストリビューションは、常に "Sid" というコードネームであり、パッケージエントリは Debian archive にアップロードされた後に unstable (sid/ へのシンボリックリンク) ディレクトリに 記録され、testing/ に移動されるまでここにあります。 上に挙げた場所に加え、pool ディレクトリに新しい 物理的なパッケージがあります。 (pool ディレクトリ, 第 2.1.10 節 参照) testing/stable/ と同じ機能を提供する maincontrib そして non-free サブディレクトリもあります。

unstable ディストリビューションには最新の開発版システムの スナップショットが含まれます。ユーザがパッケージを使ってテストするのは 歓迎されますが、これらのパッケージが準備段階にあることは警告されます。 unstable ディストリビューションを使う利点としては、 常に最新の Debian ソフトウェアプロジェクトを使えます。 — たとえシステムを壊すようなことがあったとしても、 壊れたシステムをそのままキープできます。

unstable ディストリビューションの最新バグステータスは Unstable Problems web ページで 報告されています。


2.1.6 frozen ディストリビューション

testing ディストリビューションが充分成熟すると、frozen されます。 そして、新しいコードはもはや受け付けず、必要ならばバグフィックスのみ 受け付けられます。さらに、新しい testing ツリーが dists ディレクトリに作成され、新しいコードネームを割り当てられます。 frozen ディストリビューションは数ヵ月テストされ、"テストサイクル" と呼ばれる deep freeze に入ります。 (最近の Woody リリースは froze シンボリックリンクを作成 しません。それゆえ、frozen はディストリビューションではなく、 testing ディストリビューションの開発段階です。)

パッケージのリリースを遅らせたり、リリース全体を止めてしまう frozen ディストリビューションのバグを記録し続けています。 バグ総数が最大許容数を下回ったら、frozen ディストリビューション は stable になり、リリースされます。そして以前の stable ディストリビューション は obsolete になります。(そして archive に移動します)


2.1.7 Debian ディストリビューションのコードネーム

woody/sarge/ などの、dists ディレクトリにある物理的に存在するディレクトリ名は、 単なる "コードネーム" です。Debian ディストリビューションが開発段階に あるとき、バージョン番号を持ちませんが、その代わりコードネームを持ちます。 これらのコードネームの目的は、Debian ディストリビューションのミラーリングを より簡単に行うためです。(unstable のような真のディレクトリ名が stable に突然変わると、多くの努力が無駄になり、再び ダウンロードを行わなくてはならなくなります)

現在、stablewoody/ の、 testingsarge/ のシンボリック リンクです。これは Woody が現在の stable ディストリビューションであり、Sarge が現在の testing ディストリビューションであることを意味しています。

Sid は常に unstable ディストリビューションですので、usstable/sid/ の永続的なシンボリックリンクです。


2.1.8 過去に使用されたコードネーム

過去に使われたコードネームは次の通り: release 1.1 では "Buzz", release 1.2 では "Rex", release 1.3.x では "Bo", release 2.0 では "Hamm", release 2.1 では "Slink", release 2.2 では "Potato"。


2.1.9 コードネームの由来

いままではコードネームは Pixar 作の映画 トイストーリー の キャラクター名から取られていました。


2.1.10 pool ディレクトリ

歴史的に、パッケージはパッケージを含むディストリビューションに対応した dists サブディレクトリに保持されました。これは大きな変更が 発生した場合、ミラーするのに大きなバンド幅を消費するなどのさまざまな 問題を引き起こしました。

パッケージは現在大きな "pool" に保存され、source パッケージの名前に 従って構造化されます。この "pool" を管理可能にするため、pool は セクション (main, contrib そして non-free) および source パッケージの先頭の文字により分割されます。これらのディレクトリ にはいくつかのファイル: 各アーキテクチャ用のバイナリパッケージ、そして バイナリパッケージの生成元である source パッケージが含まれます。

apt-cache showrc mypackagename のようなコマンドを 実行し、"Directory:" 行を見ることにより、パッケージの場所を見つけられます。 例えば、apache パッケージは pool/main/a/apache/ にあります。非常に多くの lib* パッケージが存在するため、これらのパッケージは特別扱いされています: 例えば、libpaper パッケージは pool/main/libp/libpaper/ に保存されています。

dists ディレクトリは依然 apt のような プログラムにより使用される索引ファイルのために使われています。また、 本文書を書いている時点では、以前のディストリビューションは pool を 使うように変換されていませんので、"Directory" ヘッダフィールドの potatowoody のようなディストリビューション名を 含むパスを見掛けるでしょう。

新しい apt や多分古い dpkg-ftp (Debian システムのアップグレード手順, 第 2.3.1 節 参照) はシームレスな処理を行うので、通常はこれらのことを心配する 必要はありません。詳細を知りたい場合は、RFC: implementation of package pools をご覧ください。


2.1.11 Sid に関するヒストリカルノート

昔 Sid は存在していませんでした。Debian archive サイトは大きな欠陥を一つ持っていました: アーキテクチャが最新の unstable に作られた時、 ディストリビューションが新しい stable になった時にそれがリリースされるという前提がありました。このケースにあてはまらない多くのアーキテクチャにとって、リリース時にこれらのディレクトリが移動しなければならないという結果となりました。この移動が膨大なバンド幅を消費するため、これは実際的ではありません。

アーキテクチャ管理者はこの問題に数年間取り掛かり、sid と 呼ばれる特別なディレクトリに未リリースのアーキテクチャのためのバイナリを置く ことにより問題を解決しました。未リリースのアーキテクチャが最初にリリースされる 場合、最新の stable/ に対し sid/ がリンク されました。そして、それ以降は通常どおり unstable 内に バイナリが作成されました。

Woody ディストリビューションの開発中にパッケージプールを (pool ディレクトリ, 第 2.1.10 節 参照) 発明したことにより、バイナリパッケージは ディストリビューションに依らずにプール内の標準的な場所に保存され始めました。 それゆえ、ディストリビューションのリリースを行っても、もはやミラー時に 大きなバンド幅を消費しません。(しかし、開発過程を通し、緩やかなバンド幅 消費が発生します。)


2.1.12 incoming/ にパッケージをアップロードする

パッケージのアップロードはそれらが本当に Debian 開発者からのものかを 検査した後に http://incoming.debian.org/ にまず置かれます。 (そしてそれがノンメンテナアップロード (NMU) の場合は、DELAYED サブディレクトリに置かれます。) 一日に一度、それらは incoming/ から unstable/ に移されます。

緊急時には、incoming/unstable/ に移る前に パッケージをインストールしたい場合があるかもしれません。


2.1.13 古いパッケージを取得する

最新の Debian ディストリビューションは Debian mirror sitedebian ディレクトリ下に保持されますが、Slink などの古い Debian ディストリビューションのアーカイブは http://archive.debian.org/ や Debian の各ミラーサイトの debian-archive ディレクトリに保存されています。

testingunstable の昔のパッケージは http://snapshot.debian.net/ にあります。


2.1.14 アーキテクチャセクション

主要なディレクトリツリーそれぞれ (dists/stable/main, dists/stable/contrib, dists/stable/non-free, dists/unstable/main/ など) の中に、バイナリパッケージエントリが パッケージがコンパイルされたアーキテクチャを示す名前を持つサブディレクトリ 内に存在します。

testingunstable 用の実際のバイナリパッケージは もはやこれらのディレクトリに無く、pool ディレクトリに あることに注意してください。しかし、索引ファイル (PackagesPackages.gz) は下位互換性のために保持されています。

実際にサポートされているバイナリパッケージについては、 各ディストリビューションのリリースノートをご覧ください。 これらは stable および testing のためのリリースノート サイトにあります。


2.1.15 ソースコード

ソースコードは Debian システムにおける全てに対して含まれます。さらに、 システムのほとんどのプログラムのライセンス事項は、ソースコードが プログラムと共に配布されるか、プログラムに添付するソースコードを 提供することを 要求します。

通常ソースコードは source ディレクトリで配布され、 アーキテクチャ特有のバイナリディレクトリ全てと並列になっているか、 より最近では pool ディレクトリにあります。 (pool ディレクトリ, 第 2.1.10 節 参照) Debian アーカイブの構造を熟知せずにソースコードを取得するには、 apt-get source mypackagename のようなコマンドを 試してみてください。

いくつかのパッケージ、とりわけ pine は そのライセンスの制限により、ソースパッケージでしか得られません。 (最近、pine-tracker パッケージが Pine のインストールを 容易にするために導入されました。stable システムへのパッケージ移植, 第 6.4.10 節 および Packaging, 第 13.9 節 に記述された手順により、パッケージを手動で構築する方法を習得できます。

公式には Debian システムの一部では無い contribnon-free ディレクトリにあるパッケージのソースコードは 入手できるかもしれませんし、できないかもしれません。


2.2 Debian パッケージ管理システム


2.2.1 Debian パッケージの概観

一般にパッケージには関連するコマンドや機能を実装するのに必要な ファイルすべてが含まれています。Debian パッケージには二つのタイプがあります:

このパッケージシステムでは、ソフトウェアをインストールするとき、 パッケージ保守担当者が注意深く設計した "依存情報" を使います。 この依存情報はそれぞれのパッケージに関連する制御 (control) ファイルに記載されています。例えば、GNU C コンパイラ (gcc) を含むパッケージは、リンカやアセンブラを含む binutils パッケージに "依存"しています。もしユーザがあらかじめ binutils をインストール していないの に gcc をインストールしようとしたなら、Debian の パッケージシステムは binutils も必要であるというエラーメッセージを 出力し、ユーザがまず binutils をインストールするのに同意するまで gcc をインストールしません (とは言うものの、頑固なユーザは この機能を上書きできます。dpkg(8) 参照) さらに詳しい情報は、パッケージの依存性, 第 2.2.8 節 下をご覧ください。

Debian のパッケージングツールは以下の用途に使えます:


2.2.2 Debian パッケージのフォーマット

Debian の "パッケージ" つまり Debian アーカイブファイルには、 実行プログラム一式や関連するプログラムのセットに関係する実行ファイルや、 ライブラリ、ドキュメントが含まれています。通常、Debian アーカイブファイルは ファイル名の最後に .deb が付いています。 [1]

Debian バイナリパッケージフォーマットの内部仕様は deb(5) マニュアルページに解説されています。このフォーマットは (Debian のメジャーリリースの間で) 変更されることがあるので、 .deb ファイルを操作する時は必ず dpkg-deb(8) を使って下さい。

少なくても Sarge ディストリビューションを通じ、全ての Debian アーカイブ ファイルは、dpkg コマンドが使えない場合であっても、 標準的な Unix コマンドである artar により操作できます。


2.2.3 Debian パッケージ名の命名規則

Debian パッケージのファイル名は次のような規則に従います:

      foo_バージョン番号-Debian リビジョン番号.deb。

ここで、foo はパッケージ名の代わりであることに注意して下さい。 照会するためには、以下の方法で特定の Debian アーカイブファイル (.deb ファイル ) に関係のあるパッケージ名を調べることができます:

VVV の部分はバージョン番号を示し、上流の開発者により指定されます。 この部分には標準がありません。バージョン番号は "19960513"や "1.3.8pre1" のようにフォーマットが異なっているかもしれません。

RRR の部分は Debian のリビジョン番号で、Debian の開発者 (か自分自身のためにパッケージをビルドすることにした個人ユーザ) が決定します。 この番号は Debian パッケージのリビジョンレベルに対応します。 したがって、リビジョンレベルが新しくなると、普通、Debian の Makefile (debian/rules) や Debian 制御ファイル (debian/control) 、インストールまたは削除スクリプト (debian/p*)、 パッケージが利用する設定ファイルなどに変更があったことを意味します。


2.2.4 ローカル設定の保存

ユーザが設定可能なファイルの保存は Debian の "conffile" 機構を通して 行えます。ユーザ設定ファイルは (通常 /etc/ に置かれる) Debian パッケージシステム内の conffile に指定されます。 パッケージ管理システムはパッケージのアップグレード時にこれらのファイルを 上書きしないことを保証します。

さまざまな Debian パッケージに所属するファイルを修正せずにシステムの 設定を行うことが可能です。通常それらが "conffile" な場合でさえも修正 しないのは良い考えです。これにより高速でスムーズな更新作業が保証されます。

アップグレード中に保持するファイルを正確に決めるには、次のコマンドを 起動します:

     dpkg --status package

そして "Conffiles:" の下を見ます。

Debian conffile ファイルの内容の特徴は Debian ポリシーマニュアル section 11.7 (References, 第 15.1 節 参照) に記述されています。


2.2.5 Debian メンテナンススクリプト

Debian メンテナンススクリプトはパッケージがインストールされる前か後で 自動的に実行される実行可能なスクリプトです。これらのファイルは control という名前のファイルと一緒にすべて Debian アーカイブファイルの "制御 (control)" セクションの一部となっています。

個々のファイルは以下の通り:

preinst
このスクリプトは、パッケージが Debian アーカイブ (.deb) ファイルからアンパックされる前に実行されます。パッケージがインストールか アップグレードし終わる ("postinst" スクリプトが正常に実行された後) まで、多くの"preinst" スクリプトの中で、更新されるパッケージのために サービスが停止されるようになっています。
postinst
このスクリプトの典型的な仕事は、Debian アーカイブファイル (.deb) からアンパックされたら、それに必要な設定をすべて完了させることです。 "postinst" スクリプトのよくある動作として、ユーザに入力を求め、 既定値を受け入れるなら後戻りしてこのパッケージを環境に沿うように 再設定することを忘れないように警告を表示します。 新しいパッケージがインストールされるかアップグレードされると、 多くの "postinst" スクリプトはサービスを開始または再開するのに 必要なコマンドをすべて実行します。
prerm
このスクリプトは典型的には、パッケージに関連したあらゆる デーモンを停止します。これはパッケージに関連したファイルを 削除する前に実行されます。
postrm
このスクリプトは典型的にはパッケージに関連したリンクや 他のファイルを修整したりパッケージが作成したファイルを削除したりします。 (仮想パッケージ, 第 2.2.7 節 も参照。)

現在、制御ファイルはすべて /var/lib/dpkg/info/ に置かれています。パッケージ foo に関係するファイルは "foo" で始まる 名前を持ち、"preinst" や "postinst" などの適当なファイル拡張子を持ちます。 このディレクトリにある foo.list というファイルは、 パッケージ foo によってインストールされたファイルがすべて リストされています (これらのファイルの存在場所は dpkg が 内部に持っていることに注意して下さい。存在場所を頼りにしないほうが いいでしょう)。


2.2.6 パッケージ優先度

それぞれの Debian パッケージには、パッケージ管理システムの助けとして、ディストリビューション保守担当者が 優先度 を割りあてています。 優先度には以下のものがあります:

パッケージの説明にある "Priority: required", "Section: base" および "Essential: yes" の違いについて注意してください。"Section: base" は 新しいシステムには他の全てをインストールする前にこのパッケージが インストールされることを意味しています。"Section: base" なパッケージの ほとんどは "Priority: required" または少なくても "Priority: important" であり、それらの多くは "Essential: yes" にタグづけられています。 "Essential: yes" はこのパッケージをシステムから削除するには、 dpkg のようなパッケージ管理システムに特別な強制オプションを 指示する必要があることを意味しています。例えば、 libc6mawkmakedev は "Priority: required" かつ "Section: base" ですが、"Essential: yes" ではありません。


2.2.7 仮想パッケージ

仮想パッケージとは、すべて同じ基本機能を提供するパッケージの集まりの どれか一つに供される一般的な名前のことです。 たとえば tintrn プログラムはどちらも ニュースリーダであり、それゆえ、動作するか利用するためににニュースリーダを 要求するプログラムの依存性を満たします。したがって両プログラムは news-reader と呼ばれる "仮想パッケージ" を供給します。

同様に、eximsendmail には両方とも メール配送エージェント (mail transport agent) の機能が備わっています。 それゆえ仮想パッケージ mail-transport-agent を 提供するといわれます。どちらかがインストールされていれば、 mail transport agent がインストールされていることに依存する プログラムはどれでもこの仮想パッケージが存在しているために 条件を満足しています。

Debian はこのようなしくみを提供するので、同じ仮想パッケージを持つ パッケージが一つ以上システムにインストールされると、システム管理者は 優先パッケージを設定できます。関連するコマンドは update-alternatives で、 Alternative コマンド, 第 6.5.3 節 で さらに詳しく述べられています。


2.2.8 パッケージの依存性

Debian パッケージシステムはパッケージ "依存性" に幅を持っています。 あるシステム上でプログラム A がプログラム B の存在からどれくらい独立して 動作させられるかを (フラグ一つで) 表示するよう設計されています:

これらの用語の使用法についてのより詳しい情報は Debian パッケージング マニュアルDebian ポリシーマニュアル にあります。

単に depends と指定されたパッケージ全てを取得しますが、 recommendssuggests と指定された パッケージを全て無視する apt-get に比べ、dselect はより洗練した recommendssuggests により指定されるパッケージ制御機能を有します。これらのプログラムは共に 現代的な形で APT をバックエンドとして使用します。


2.2.9 "pre-depends" の意味

"Pre-depends" は特別な依存関係です。通常のパッケージの場合、 dpkg はアーカイブファイル (すなわち .deb ファイル)を 依存するファイルがシステム上にあるかにどうかに係わらず独立に展開します。 展開は基本的に dpkg がファイルシステム上にインストールされる アーカイブファイルからファイルを取り出し、ある場所に置くことを意味します。 それらのパッケージがシステム上にある他のパッケージの存在に 依存している場合、dpkg は他のパッケージがインストールされるまで、 (その "configure" 動作を実行せずに) インストールの完了を拒絶します。

しかしながら、あるパッケージは依存性が解決されるまで、dpkg が パッケージファイルの展開さえ拒否します。 そのようなパッケージは他のパッケージの存在に "pre-depends" する と言われます。Debian プロジェクトは、パッケージを展開する 順番が非常に重要であった a.out フォーマットから ELF フォーマットへの システムの安全な更新をサポートするためにこの機構を導入しました。 この方法が有効な大規模なアップグレード状況もあります。例えば、"required" 優先度を持ち、libc に依存するパッケージを更新する場合などです。

先の項目と同様に、本機構に関するより詳しい情報は パッケージマニュアル にあります。


2.2.10 パッケージステータス

パッケージステータスには "unknown", "install", "remove", "purge" "hold" があります。 これらの "want" フラグは利用者がそのパッケージをどう扱いたいかを示しています。 利用者は dselect の "Select" セクションでのアクション や dpkg の直接起動によってこれを示すことができます。

それぞれの意味は以下の通り:


2.2.11 更新からパッケージをホールドする

パッケージを hold するには二つの方法があります。dpkg を使う方法と、Woody から始まった APT を使う方法です。

dpkg では、パッケージ選択の一覧を

     dpkg --get-selections \* > selections.txt

で書き出すだけです。それから書き出されたファイル selections.txt を編集して hold したいパッケージの行を変更します。例えば:

     libc6                       install

     libc6                       hold

にします。ファイルを保存して、

     dpkg --set-selections < selections.txt

でdpkg データベースに再ロードしてください。又、ホールドしたいパッケージ名 を知っている場合は、単に

     echo libc6 hold | dpkg --set-selections

を実行するだけです。この手順は各パッケージファイルのインストール処理で パッケージをホールドします。

同様の効果が dselect を通しても得られます。[S]elect 画面に 入って hold したいパッケージの現在の状態を確認し、「=」キー (もしくは「H」キー) を押下するだけです。変更は [S]elect 画面を終了するとすぐに反映します

Woody ディストリビューションにおける APT システムは Pin-Priority を用いてアーカイブ取得処理中にパッケージをホールドする新しいもう一つの機構 を持ちます。 http://www.debian.org/doc/manuals/apt-howto/ と共に、マニュアルページ apt_preferences(5) をご覧ください。 apt-howto パッケージの /etc/apt/preferences の概観, 第 6.2.8 節 にも簡潔な説明があります。


2.2.12 ソースパッケージ

ソースパッケージは source と呼ばれるディレクトリで配布されています。手動でダウンロードできますし、

     apt-get source foo

を使ってダウンロードもできます。 (このための APT の設定法については apt-get(8) マニュアルページを参照してください)。 apt-get source foo を使って取得することもできます (このための APT の設定法については apt-get(8) を参照願います。)


2.2.13 ソースパッケージからバイナリパッケージを作る

パッケージ foo をソースからコンパイルするには、 foo_*.dscfoo_*.tar.gz および foo_*.diff.gz の全てが必要となります (注意:Debian 固有のパッケージに は .diff.gz はありません)。

これらを入手し、dpkg-dev パッケージをインストールしている場合、

     $ dpkg-source -x foo_version-revision.dsc

というコマンドを実行すれば foo-version というディレクトリ にパッケージが取り出されます。

バイナリパッケージをコンパイルしたいならば、

     $ cd foo-version
     $ su -c "apt-get update ; apt-get install fakeroot"
     $ dpkg-buildpackage -rfakeroot -us -uc

を実行し、

     # su -c "dpkg -i ../foo_version-revision_arch.deb"

で新たに構築したパッケージをインストールします。stable システムへのパッケージ移植, 第 6.4.10 節 をご覧ください。


2.2.14 新しい Debian パッケージを作る

新しいパッケージを作ることに関する詳細な情報は、 maint-guide パッケージで得られる Debian メンテナ入門 又は http://www.debian.org/doc/manuals/maint-guide/ をご覧ください。


2.3 Debian システムのアップグレード

Debian の目標の一つは首尾一貫したアップグレード方針と安全な アップグレード手順を提供することであり、前のリリースから新リリースに スムーズにアップグレードできるよう我々は常に最善を尽しています。 アップグレード手順に加えるべき何か重要な注記事項がある場合には、 パッケージはユーザに注意を促し、ありうる問題への解決法を提供します。

アップグレードの詳細を具体的に解説したリリースノートも読んでおくべきです。 これはすべての Debian CD と一緒に出荷されており、WWW でも http://www.debian.org/releases/stable/releasenoteshttp://www.debian.org/releases/testing/releasenotes で利用可能です。

アップグレードを行う実際的なガイドは Debian パッケージ管理, 第 6 章 で供給されます。 本章では基本的な手順を記述します。


2.3.1 Debian システムのアップグレード手順

単純に Debian アーカイブに匿名 ftp または wget をかけ、次に ディレクトリをよく調べて、欲しいファイルを見つけ、それを取ってきます。 最後に dpkg を使ってそのファイルをインストールします。 (たとえシステムが稼動していても、 dpkg はアップグレードする 必要のあるファイルをきちんとインストールしてくれることに注意してください。) しかし、あるパッケージをアップグレードしようとした時、他のパッケージも アップグレードするように要求される場合があります。この場合、 指示されたアップグレードを行うまで、あるいは行わなければ、 希望するパッケージのアップグレードは失敗してしまいます。

この方法はあまりにも時間がかかり過ぎると多くの人が感じるでしょう。 というのも Debian は急速に進化しているからです。通常、一週間に 1 ダース 以上もの新しいパッケージがアップロードされています。 新しいメジャーリリースの直前にはもっと増えます。このような大変な アップグレード作業を自動化してくれるプログラムを使いたいという人が 多くいます。このためにいくつかの専用のパッケージが利用できます


2.3.2 パッケージ管理ツールの概要

Debian パッケージ管理システムには二つの目的があります:パッケージファイル自身の操作と Debian アーカイブからのパッケージファイルの取得です。dpkg は前者の作業を行い、APT や dselect は後者です。


2.3.3 dpkg

これはパッケージファイルの操作のための主要なプログラムです。 完全な説明は dpkg(8) を読んでください。

dpkg にはいくつかの原始的な補助部プログラムが付随します。

dpkg-ftpdpkg-mountable は APT システムに 取って代わられました。


2.3.4 APT

APT (the Advanced Packaging Tool) は Debian パッケージングシステムの先進的なインターフェースであり、"apt-" で始まる名前を持ついくつかのプログラムから 構成されています。 apt-getapt-cache および apt-cdrom はパッケージ操作用のコマンドラインツールです。これらには dselectaptitude のような他のツールへのユーザ "バックエンド" としても働きます。

より詳しい情報は、apt パッケージをインストールし、 apt-get(8)apt-cache(8)apt-cdrom(8)apt.conf(5) sources.list(5), apt_preferences(5) (Woody)、そして /usr/share/doc/apt/guide.html/index.html を読んでください。

もう一つの情報源としては、 APT HOWTO があります。 /usr/share/doc/Debian/apt-howto/apt-howto によりインストールできます。

apt-get upgradeapt-get dist-upgrade は "Depends:" にリストされたパッケージのみを引っ張ってきますが、 "Recommends:" や "Suggests:" にリストされたパッケージは無視します。 これを避けるには、dselect を御使用ください。


2.3.5 dselect

このプログラムは Debian パッケージ管理システムへのメニュドリブンな ユーザインターフェースです。最初のインストール時や大規模なアップグレード時 に特に役立ちます。dselect, 第 6.2.3 節 をご覧ください。

より詳しい情報は、install-doc パッケージをインストールし、 /usr/share/doc/install-doc/dselect-beginner.en.htmldselect Documentation for Beginners を読んでください。


2.3.6 起動中のシステムをアップグレードする

Debian システムにおける kernel (ファイルシステム) はファイルを使用中で な場合でさえも、そのファイルの置き換えをサポートしてます。

ブート時にデーモンを起動したり、kernel のランレベルが変更された時 (例えば、マルチユーザからシングルユーザにとか、"halt" などに変更した時) にデーモンを停止したりするために用いる start-stop-daemon と呼ばれる プログラムも提供しています。同じプログラムは、デーモンを含む新パッケージを インストールした時に、起動中のデーモンを停止したり必要な場合に デーモンを再起動するため、インストールスクリプトにより使用されます。

Debian システムは起動中のシステムをアップグレードするのに シングルユーザモードを必要としないことに注意してください。


2.3.7 .deb アーカイブファイルのダウンロードとキャッシュ

手動でパッケージファイルをディスクにダウンロードした場合、(これは必ずしも必要ではありません。上に記述した dpkg-ftp または APT の説明をご覧ください) パッケージをインストールした後、システムから .deb ファイルを削除できます。

APT を使っている場合、これらのファイルは /var/cache/apt/archives ディレクトリにキャッシュされます。これらをインストール後に削除 (apt-get clean) できますし、その後のインストール中のダウンロード時間を節約するため、 他のマシーンの /var/cache/apt/archives ディレクトリにコピー してもかまいません。


2.3.8 アップグレードの記録を取る

dpkg は展開、設定、削除またはパージされたパッケージの記録を取ります が、 (現在) パッケージにそのような操作が行われている間に起こったターミナル上の コマンドログを取っていません。

コマンドログを取る最もシンプルな方法は、dpkgdselectapt-get などのセッションを script(1)プログラム内で起動することです。


2.4 Debian ブートプロセス


2.4.1 init プログラム

他の Unix ライク OS と同様に、Debian は init プログラムを 実行することによりブートを始めます。init 用の設定ファイル (/etc/inittab) は、実行されるべき最初のスクリプトが /etc/init.d/rcS であることを指定しています。 このスクリプトは /etc/rcS.d/ 下にあるスクリプトをそのファイル 拡張子に応じて、読み込むか、サブプロセスを fork することにより 初期化処理を実行します。その初期化処理には、ファイルシステムのチェックやマウント、モジュールの読み込み、ネットワークサービスの開始、時計の設定などが含まれます。そして、互換性のために、/etc/rc.boot/ 下にあるファイル (ファイル名に `.' が付くファイルを除く) も実行します。後者のディレクトリ内のスクリプトは通常システム管理者が使用するために予約されており、パッケージがこのディレクトリにスクリプトを置くのは時代遅れです。詳細は Debian ポリシーマニュアルの System initialization, 第 9.1 節System run levels and init.d scripts をご覧ください。


2.4.2 Runlevels

ブートプロセス完了後、init は (/etc/inittabid 用のエントリにより与えられる) 標準のランレベルにより指定された ディレクトリ内の全ての起動スクリプトを実行します。 全ての System V 互換 Unix と同様に、Linux は7個のランレベルを持ちます:

Debian システムの id は 2 であり、これは標準のランレベルが ランレベル 2 のマルチユーザ状態であり、/etc/rc2.d/ 下のスクリプトを実行することを示しています。

実は、/etc/rcN.d/ ディレクトリにあるスクリプトはいずれも /etc/rcN.d/ にあるスクリプトの単なるシンボリックリンクです。しかし、/etc/rcN.d/ ディレクトリにあるそれぞれのファイルの 名前/etc/init.d/ にある スクリプトが起動される 方法 を示すように選ばれています。 特に、ランレベルに入る前に、 `K' で始まる全てのスクリプトが起動されます。 これらのスクリプトは全てのサービスを殺します。そして `S' で始まるスクリプト が全て起動されます。これらのスクリプトはサービスを開始します。`K' や `S' に続く 2桁の番号はスクリプトの起動される順番を示します。小さい番号が付いたスクリプトは 早く実行されます。

/etc/init.d/ にあるスクリプトは全て "start"、 "stop"、 "reload"、 "force-reload" の四個の引数を取り、引数により指定された仕事を行うため、この手法は機能します。これらのスクリプトはさまざまなプロセスを制御するために、 システムがブートした後でも使えます。

例えば、"reload" 引数をコマンドに持たせると、

     # /etc/init.d/sendmail reload

設定ファイルを再読み込みするように sendmail デーモンにシグナルを送ります。


2.4.3 ブートプロセスのカスタマイズ

Debian はブートプロセスをカスタマイズするのに BSD スタイルの rc.local ディレクトリを使用しません。その代わり、カスタマイズのために 次に述べる機構を供給します。

システムが起動時又は特定の (System V) ランレベルにおいて foo というスクリプトを実行する必要があると想定します。そのとき、システム管理者が すべきなのは次の通り:

  1. スクリプト foo/etc/init.d/ ディレクトリに 入れる。
  1. Debian コマンド update-rc.d を適切な引数を使って 起動し、(コマンドラインで指定した) rc?.d ディレクトリ と /etc/init.d/foo のリンクを設定する。 ここで、? は System V ランレベルのうちのどれかに対応する 0 から 6 までの番号。
  1. システムをリブートする。

update-rc.d コマンドは rc?.d ディレクトリと /etc/init.d/ にあるスクリプトの間のリンクを設定します。各リンクは `S' 又は `K' で始まり、その後ろに番号、そしてスクリプトの名前が続きます。 システムがランレベル N に入ると、/etc/rcN.d/ 内の `K' で始まるスクリプトが引数 stop により実行され、次に /etc/rcN.d/ 内の `S' で始まるスクリプトが 引数 start により実行されます。

例えば、スクリプト foo をブート時に実行させたい場合、そのスクリプトを /etc/init.d/ に置いて、update-rc.d foo defaults 19 を実行してリンクを張ります。引数 defaults は 2 から 5 の標準ランレベルを参照します。引数 19foo が番号 20 以上を持つスクリプト よりも前に実行されることを保証します。


2.5 多様性のサポート

Debian はシステムを壊さずにシステム管理者の希望を満たすためのいくつかの手段 を提供します。

/usr/local/ 以下のファイルはシステム管理者のものであり、 Debian は一切触りません。 /etc 以下のほとんど (又は全ての) ファイルは conffiles であり、Debian はシステム管理者が明示的に 要求しない限りアップグレード時に上書きしません。


2.6 国際化

Debian システムは国際化されており、コンソール上ならびに X 上で 多種の言語の文字を表示し、入力するためのサポートを供給します。 たくさんのドキュメント、マニュアルページ、そしてシステムメッセージが翻訳されており、翻訳されている言語は増加し続けています。インストール中、Debian は ユーザにインストール言語 (そして時々はローカル言語変数 )の選択を促します。

あなたが必要な言語の機能全てをインストールしたシステムがサポートしていない場合、又はあなたの言語をサポートするために言語の変更や、異なるキーボードのインストールが必要な場合、ローカライゼーション, 第 9.7 節 をご覧ください。


2.7 Debian と kernel

Debian での Linux kernel, 第 7 章 をご覧ください。


2.7.1 非 Debian なソースから kernel をコンパイルする

header に関する Debian ポリシーを理解する必要があります。

Debian C ライブラリは kernel header の最新の stable リリースを用いて構築されています。

例えば、Debian-1.2 リリースは version 5.4.13 のヘッダを用いていました。 この慣習は全ての Linux FTP アーカイブサイトにおいて配布される Linux kernel ソースパッケージに対照しており、Linux kernel ソースパッケージはより最新 の header を使ってさえいます。kernel source により配布される kernel header は /usr/include/linux/include/ にあります。

libc6-dev により供給されるものより新しい kernel header を用いて プログラムをコンパイルする必要がある場合には、コンパイル時、コマンドラインに -I/usr/src/linux/include/ を付け加える必要があります。 これは、例えば automounter daemon (amd) のパッケージングをする 場合に使われます。新しい kernel が NFS を扱うための内部処理を変更した場合、 amd はそれを知る必要があるため、最新の kernel header を 含める必要性が発生します。


2.7.2 カスタム kernel 構築ツール

カスタム kernel を構築したい (する必要がある) 人は kernel-package パッケージのダウンロードが推奨されます。本パッケージには kernel パッケージ の構築用スクリプトが副まれ、次のようなコマンドを kernel ソースディレクトリの 最上段で実行するだけで Debian kernel-image パッケージを構築する機能を供給します。

     # make-kpkg kernel_image

ヘルプは次のコマンドを実行すると得られます。

     # make-kpkg --help

また、マニュアルページ make-kpkg(8) 全体と Debian での Linux kernel, 第 7 章 も参照願います。

kernel-source-version (version は kernel バージョンを 表す) パッケージが得られない場合、好みの Linux アーカイブサイトから最新の kernel (又は選んだ kernel) のソースコードを別途ダウンロードする必要があります。 Debian の initrd ブートスクリプトは initrd と呼ばれる 特別な kernel patch を要求します。http://bugs.debian.org/149236 をご覧ください。

kernel-package パッケージの詳細な使用方法は /usr/share/doc/kernel-package/README.gz にあります。


2.7.3 代替ブートローダ

grubloadlin のような代替ブートローダを使いたい場合、 コンパイルした Linux kernel bzimage を他の場所 (例えば、/boot/grub や MS-DOS パーティション) にコピーしましょう。


2.7.4 カスタムブートフロッピ

カスタムブートフロッピを作成する作業は、通常 Debian FTP アーカイブの admin セクションにある Debian パッケージ boot-floppies により、大きな手助けが得られます。本パッケージにあるシェルスクリプトはブートフロッピを syslinux フォーマットで作成します。これらは MS-DOS フォーマット され、直接 Linux (又はsyslinux.cfg で定義された他のオペレーションシステム) をブートするようにマスターブートレコードが変更されたフロッピです。 本パッケージの他のスクリプトは緊急 root ディスクを作成し、base ディスクの再製作さえできます。

詳細は boot-floppies パッケージをインストールした後、 /usr/doc/boot-floppies/README ファイルをご覧ください。


2.7.5 モジュールを扱うための特別な準備

Debian の modconf パッケージはモジュールの設定をカスタマイズする ために使用できるシェルスクリプト (/usr/sbin/modconf) を供給 します。このスクリプトはメニュベースのインターフェースを表示し、システムの ローダブルデバイスドライバに関する詳細に対してユーザを促します。 その応答は /etc/modules.conf/etc/modules をカスタマイズするのに使用されます (これらにはブート時にロードされる モジュールがリストされています)。

カスタム kernel の構築をサポートするために得られる (新しい) Configure.help ファイルと同様に、modconf パッケージには モジュールそれぞれに対して適切な引数についての詳細な情報を供給する (/usr/share/modconf/ にある) ヘルプファイルが付属します。用例は モジュール化された 2.4 kernel, 第 7.2 節 をご覧ください。


2.7.6 古い kernel パッケージを削除する

kernel-image-NNN.prerm スクリプトは現在起動している kernel が削除しようとしている kernel と同じかどうかチェックします。それゆえ、 使わない kernel image パッケージを安全に次のコマンドを用いて削除できます:

     dpkg --purge --force-remove-essential kernel-image-NNN

(もちろん、NNN を削除したい kernel のバージョンとリビジョンに置き換えます。)


[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ 次のページ ]

Debian レファレンス

1.07-1, 2004年 3月 7日 日曜日 15時48分58秒 UTC時間

Osamu Aoki (青木 修) osamu@debian.org
翻訳: 角田 慎一 tsuno@ngy.1st.ne.jp
著者, 第 A.1 節