本章は非開発者のために Debian システムの基礎的な情報を供給します。 信頼できる情報が欲しい場合は、次を参照してください。
参考文献, 第 15.1 節 にリストされています。
あまり詳しくない "how-to" 的な説明を探している場合、 Debian パッケージ管理, 第 6 章 や他の該当する章にすぐ飛んでください。
本章は "Debian FAQ" から取られた文書に基づき、通常の Debian システム管理者が始められるように大規模な再構成を行いました。
Debian 用にパッケージングされているソフトウェアは Debian mirror site
のそれぞれのいくつかの ディレクトリツリーの一つから FTP 並びに HTTP
経由で取得できます。
次のディレクトリは 各 Debian ミラーサイトの debian
ディレクトリの下で見つかります。
dists/:Contents-*.gz や Packages.gz もまだここにあります。
pool/:tools/:doc/:indices/:project/:project/experimental/:project/orphaned/:
通常 dists ディレクトリには 3種類の Debian
ディストリビューションが存在します。これらは stable.
testing そして unstable と呼ばれます。 時々
frozen も存在します。各ディストリビューションは dists
ディレクトリにある、コードネームが付いた
実際のディレクトリのシンボリックリンクとして定義されています。
stable ディストリビューション, Debian Woody (3.0r0) 用のパッケージ
エントリは stable (woody/ への シンボリックリンク)
ディレクトリに記録されています。
stable/main/: このディレクトリには Debian
システムの最新の公式リリースに属する バージョンのパッケージが含まれます。
これらのパッケージは全てフリーです。すなわち、これらは全て Debian Free Software
Guidelines (DFSG) に適合しています。(debian-doc により
インストールされる /usr/share/doc/debian/social-contract.txt
としても 得られます。)
stable/non-free/: このディレクトリには DFSG
に従ってフリーと認定されないパッケージが含まれます。
例えば、いくつかのパッケージは商用配布を禁止するライセンスを持っています。 また、あるパッケージは再配布可能ですが、実はシェアウェアです。
stable/contrib/: このディレクトリには それら自体は DFSG-free
ですが、DFSG-free ではない
パッケージになぜか依存しているパッケージです。
現在は、上に挙げた場所に加えて、pool ディレクトリに新しい
物理的なパッケージがあります。 (pool
ディレクトリ, 第 2.1.10 節 参照)
stable ディストリビューションの最新バグステータスは Stable
Problems web ページに 報告されています。
testing ディストリビューション、Debian Sarge のパッケージ
エントリは unstable でしばらくテストを受けた後に
testing (sarge/ への シンボリックリンク)
ディレクトリに記録されます。 上に挙げた場所に加え、pool
ディレクトリに新しい 物理的なパッケージがあります。 (pool ディレクトリ, 第 2.1.10 節 参照)
testing/ に stable/ と同じ機能を提供する
main、contrib そして non-free
サブディレクトリもあります。
これらのパッケージはビルドされる全てのアーキテクチャで同期を取られ、
インストール可能でなくてはなりません。また、unstable
にあるバージョンよりも release-critical bug が少なくてはなりません。
このように、testing は常に release candidate 間近であることを
希望しています。testing のメカニズムの詳細については http://www.debian.org/devel/testing
にあります。
testing ディストリビューションの最新バグステータスはこれらのサイト で報告されています。
update
excuses
testing
problems
release-critical
bugs
base system
bugs
bugs in standard
and task packages
other bugs and bug-squashing party
notes
unstable ディストリビューションは、常に "Sid"
というコードネームであり、パッケージエントリは Debian archive
にアップロードされた後に unstable (sid/
へのシンボリックリンク) ディレクトリに 記録され、testing/
に移動されるまでここにあります。 上に挙げた場所に加え、pool
ディレクトリに新しい 物理的なパッケージがあります。 (pool ディレクトリ, 第 2.1.10 節 参照)
testing/ に stable/ と同じ機能を提供する
main, contrib, そして non-free
サブディレクトリもあります。
unstable ディストリビューションには最新の開発版システムの スナップショットが含まれます。ユーザがパッケージを使ってテストするのは 歓迎されますが、これらのパッケージが準備段階にあることは警告されます。 unstable ディストリビューションを使う利点としては、 常に最新の Debian ソフトウェアプロジェクトを使えます。 — たとえシステムを壊すようなことがあったとしても、 壊れたシステムをそのままキープできます。
unstable ディストリビューションの最新バグステータスは Unstable
Problemsweb ページで 報告されています。
testing ディストリビューションが充分成熟すると、frozen されます。
そして、新しいコードはもはや受け付けず、必要ならばバグフィックスのみ
受け付けられます。さらに、新しい testing ツリーが dists
ディレクトリに作成され、新しいコードネームを割り当てられます。 frozen
ディストリビューションは数ヵ月テストされ、"テストサイクル" と呼ばれる
deep freeze に入ります。 (最近の Woody リリースは froze
シンボリックリンクを作成 しません。それゆえ、frozen
はディストリビューションではなく、 testing
ディストリビューションの開発段階です。)
パッケージのリリースを遅らせたり、リリース全体を止めてしまう frozen ディストリビューションのバグを記録し続けています。 バグ総数が最大許容数を下回ったら、frozen ディストリビューション は stable になり、リリースされます。そして以前の stable ディストリビューションは obsolete になります。(そして archive に移動します)
woody/ や sarge/ などの、dists
ディレクトリにある物理的に存在するディレクトリ名は、 単なる
"コードネーム" です。Debian ディストリビューションが開発段階に
あるとき、バージョン番号を持ちませんが、その代わりコードネームを持ちます。
これらのコードネームの目的は、Debian ディストリビューションのミラーリングを
より簡単に行うためです。(unstable のような真のディレクトリ名が
stable に突然変わると、多くの努力が無駄になり、再び
ダウンロードを行わなくてはならなくなります)
現在、stable は woody/ の、 testing は
sarge/ のシンボリック リンクです。これは Woody
が現在の stable ディストリビューションであり、Sarge が現在の
testing ディストリビューションであることを意味しています。
Sid は常に unstable ディストリビューションですので、unstable/ は
sid/ の永続的なシンボリックリンクです。
過去に使われたコードネームは次の通りです。 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", release 3.0 では "Woody", release 3.1 では "Sarge"。
いままではコードネームは Pixar 作の映画 トイストーリー の キャラクター名から取られていました。
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" ヘッダフィールドの
potato や woody のようなディストリビューション名を
含むパスを見掛けるでしょう。
新しい apt や多分古い dpkg-ftp
はシームレスな処理を行うので、通常は
これらのことを心配する必要はありません。詳細を知りたい場合は、 RFC:
implementation of package pools をご覧ください。
昔 Sid は存在していませんでした。Debian archive サイトは大きな欠陥を
1つ持っていました。アーキテクチャが最新の unstable
に作られると、ディストリビューションが新しい stable になった時に
それがリリースされるという前提がありました。このケースにあてはまらない
多くのアーキテクチャにとって、リリース時にこれらのディレクトリが移動
しなければならないという結果となりました。この移動が膨大なバンド幅を
消費するため、これは実際的ではありません。
アーキテクチャ管理者はこの問題に数年間取り掛かり、sid と
呼ばれる特別なディレクトリに未リリースのアーキテクチャのためのバイナリを置く
ことにより問題を解決しました。未リリースのアーキテクチャが最初にリリースされる
場合、最新の stable/ に対し sid/ がリンク
されました。そして、それ以降は通常どおり unstable 内に
バイナリが作成されました。
Woody ディストリビューションの開発中にパッケージプールを (pool ディレクトリ, 第 2.1.10 節 参照)
発明したことにより、バイナリパッケージは
ディストリビューションに依らずにプール内の標準的な場所に保存され始めました。
それゆえ、ディストリビューションのリリースを行っても、もはやミラー時に
大きなバンド幅を消費しません。(しかし、開発過程を通し、緩やかなバンド幅
消費が発生します。)
incoming/ にパッケージをアップロードする
パッケージのアップロードはそれらが本当に Debian 開発者からのものかを
検査した後に http://incoming.debian.org/
にまず置かれます。 (そしてそれがノンメンテナアップロード (NMU)
の場合は、DELAYED サブディレクトリに置かれます。) 1日に
1度、それらは incoming/ から unstable/ に移されます。
緊急時には、incoming/ が unstable/ に移る前に
パッケージをインストールしたい場合があるかもしれません。
最新の Debian ディストリビューションは Debian mirror site の
debian ディレクトリ下に保持されますが、Slink などの古い Debian
ディストリビューションのアーカイブは http://archive.debian.org/ や
Debian の各ミラーサイトの debian-archive
ディレクトリに保存されています。
testing や unstable の昔のパッケージは http://snapshot.debian.net/
にあります。
主要なディレクトリツリーそれぞれ (dists/stable/main,
dists/stable/contrib, dists/stable/non-free,
dists/unstable/main など) の中に、バイナリパッケージエントリが
パッケージがコンパイルされたアーキテクチャを示す名前を持つサブディレクトリ
内に存在します。
binary-all/: アーキテクチャに依存しないパッケージ用。
これらには例えば、Perl スクリプトや、純粋なドキュメントが含まれます。
binary-platform/: 特定のバイナリ
プラットフォームで実行するパッケージ用。
testing と unstable 用の実際のバイナリパッケージは
もはやこれらのディレクトリに無く、pool ディレクトリに
あることに注意してください。しかし、索引ファイル (Packages と
Packages.gz) は下位互換性のために保持されています。
実際にサポートされているバイナリパッケージについては、
各ディストリビューションのリリースノートをご覧ください。 これらは stable
および testing
のためのリリースノート サイトにあります。
ソースコードは Debian システムにおける全てに対して含まれます。さらに、 システムのほとんどのプログラムのライセンス事項は、ソースコードが プログラムと共に配布されるか、プログラムに添付するソースコードを 提供することを 要求します。
通常ソースコードは source ディレクトリで配布され、
アーキテクチャ特有のバイナリディレクトリ全てと並列になっているか、 より最近では
pool ディレクトリにあります。 (pool ディレクトリ, 第 2.1.10 節 参照) Debian
アーカイブの構造を熟知せずにソースコードを取得するには、 apt-get source
mypackagename のようなコマンドを 試してみてください。
いくつかのパッケージ、とりわけ pine は
そのライセンスの制限により、ソースパッケージでしか得られません。
(最近、pine-tracker パッケージが Pine のインストールを
容易にするために導入されました。stable
システムへのパッケージ移植, 第 6.4.10 節 や パッケージング, 第 13.10 節
に記述された手順により、パッケージを手動で構築する方法を習得できます。
公式には Debian システムの一部では無い contrib や
non-free ディレクトリにあるパッケージのソースコードは
入手できるかもしれませんし、できないかもしれません。
一般にパッケージには関連するコマンドや機能を実装するのに必要な ファイルすべてが含まれています。Debian パッケージには 2つのタイプがあります。
dpkg を用いて展開できます。詳細は dpkg
の マニュアルページに記載されてあります。
dpkg-source ユーティリティは Debian
ソースアーカイブをパックしたりアンパックしたりします。
詳細はdpkg-source のマニュアルページに記載されています。
このパッケージシステムでは、ソフトウェアをインストールするとき、
パッケージ保守担当者により宣言された "依存情報" を使います。
この依存情報はそれぞれのパッケージに関連する 制御 (control)
ファイルに記載されています。例えば、GNU C コンパイラ (gcc)
を含むパッケージは、リンカやアセンブラを含む binutils パッケージに
"依存"しています。もしユーザがあらかじめ binutils
をインストール していないの に gcc
をインストールしようとしたなら、Debian の パッケージシステムは
binutils も必要であるというエラーメッセージを 出力し、ユーザがまず
binutils をインストールするのに同意するまで gcc
をインストールしません (とは言うものの、頑固なユーザは
この機能を上書きできます。dpkg(8) 参照) さらに詳しい情報は、パッケージの依存性, 第 2.2.8 節 下をご覧ください。
Debian のパッケージングツールは以下の用途に使えます。
Debian の "パッケージ" つまり Debian アーカイブファイルには、 実行プログラム一式や関連するプログラムのセットに関係する実行ファイルや、 ライブラリ、ドキュメントが含まれています。通常、Debian アーカイブファイルは ファイル名の最後に .deb が付いています。 [1]
Debian バイナリパッケージフォーマットの内部仕様は deb(5)
マニュアルページに解説されています。 このフォーマットは (Debian
のメジャーリリースの間で) 変更されることが あるので、.deb
ファイルを操作する時は必ず dpkg-deb(8) を使って下さい。
少なくても Sarge ディストリビューションを通じ、全ての Debian アーカイブ
ファイルは、dpkg コマンドが使えない場合であっても、 標準的な Unix
コマンドである ar や tar により操作できます。
Debian パッケージのファイル名は次のような規則に従います。
foo_バージョン番号-リビジョン番号__アーキテクチャ.deb
ここで、通常 foo はパッケージ名であり、var は 上流のバージョン番号、rev は Debian でのリビジョン番号、 そして arch はターゲットのアーキテクチャです。 ファイルはもちろん簡単に改名できます。 次のコマンドを実行することにより、filename という名前の ファイルに含まれているパッケージを調べることができます。
dpkg --info filename
Debian のリビジョン番号は Debian 開発者又はパッケージを構築した人 により指定されます。通常リビジョン番号の変更はパッケージングの観点から 変更が加えられたことを意味しています。
ローカルの管理者により変更可能とされているファイルは /etc/
に保持されています。 Debian
ポリシーはローカルの設定可能なファイルへの全ての変更が
パッケージのアップグレードを通じて保持されるべきであることを指示しています。
ローカルの設定可能なファイルの標準のバージョンがパッケージ自身に 含まれている場合、そのファイルは "conffile" としてリストされます。 パッケージは管理者の許可無しで最後にインストールされたので、 パッケージ管理システムは管理者により変更された conffile を更新しません。 一方、conffile が管理者により変更されていないと、パッケージの他のファイル と一緒に conffile もアップグレードされます。 これはほとんど常に好ましく、conffile への変更を最小限にすることは好都合です。
パッケージに所属する conffile をリストするには、次のコマンドを実行します。
dpkg --status package
このリストの "Conffiles:" 行に conffile が表示されます。
conffile に関するより詳しい情報については、Debian ポリシーマニュアルの "Configuration files" という章を読んでください。(参考文献, 第 15.1 節 参照)
Debian メンテナンススクリプトはパッケージがインストールされる前か後で
自動的に実行される実行可能なスクリプトです。これらのファイルは
control という名前のファイルと一緒に全て Debian
アーカイブファイルの "制御 (control)"
セクションの一部となっています。
個々のファイルは以下の通りです。
現在、制御ファイルは全て /var/lib/dpkg/info/
に置かれています。パッケージ foo に関係するファイルは
"foo" で始まる 名前を持ち、"preinst" や
"postinst" などの適当なファイル拡張子を持ちます。
このディレクトリにある foo.list というファイルは、 パッケージ
foo によってインストールされたファイルがすべて リストされています
(これらのファイルの存在場所は dpkg が
内部に持っていることに注意して下さい。存在場所を頼りにしないほうが
いいでしょう)。
それぞれの Debian パッケージには、パッケージ管理システムの助けとして、 ディストリビューション保守担当者が 優先度 を割りあてています。 優先度には以下のものがあります。
システムの欠陥を修復するのに必要なツールをすべて含みます。
これらのパッケージを消去してはいけません。システムがすっかり破壊され、 復旧
するために dpkg を使うことすら恐らくできなくなります。 Required
パッケージだけのシステムは恐らく使いものになりませんが、
システム管理者が起動したり他のソフトウェアをインストールするだけの
機能はあります。
Required 以外のパッケージで、無いとシステムがうまく動かなかったり 不便だったりするものにこの優先度がつけられています。これには Emacs や X11、TeX 他の巨大なアプリケーションは含まれていません。 ここのパッケージは、素のインフラストラクチャを構成するだけです。
これはユーザが何も指示しなかったらデフォルトでインストールされます。 多くの巨大なアプリケーションは含まれませんが、Emacs はあります (これはアプリケーションというよりも多くのプログラムのための インフラストラクチャの一部です) し、TeX と LaTeX の手頃なサブセットが (X なしで稼動可能な部分なら) 含まれています。
これには X11 や TeX 配布物全体、多くのアプリケーションが含まれています。
パッケージの説明にある "Priority: required", "Section:
base" および "Essential: yes"
の違いについて注意してください。"Section: base" は
新しいシステムには他の全てをインストールする前にこのパッケージが
インストールされることを意味しています。"Section: base"
なパッケージの ほとんどは "Priority: required" または少なくても
"Priority: important" であり、それらの多くは "Essential:
yes" にタグづけられています。 "Essential: yes"
はこのパッケージをシステムから削除するには、 dpkg
のようなパッケージ管理システムに特別な強制オプションを
指示する必要があることを意味しています。例えば、 libc6、
mawk や makedev は "Priority: required"
かつ "Section: base" ですが、"Essential: yes"
ではありません。
仮想パッケージとは、すべて同じ基本機能を提供するパッケージの集まりの
どれか一つに供される一般的な名前のことです。 例えば、 tin と
trn プログラムはどちらも
ニュースリーダであり、それゆえ、動作するか利用するためにニュースリーダを
要求するプログラムの依存性を満たします。したがって、両プログラムは
news-reader と呼ばれる "仮想パッケージ" を供給します。
同様に、exim 、exim4、sendmail、
postfix のような多くのパッケージは メール配送エージェント (mail
transport agent) の機能を備えているために 仮想パッケージ
mail-transport-agent を
提供すると言われます。これらのうちどれかがインストールされていれば、 mail
transport agent がインストールされていることに依存する
プログラムはどれでもこの仮想パッケージが存在しているために
条件を満足しています。
Debian はこのようなしくみを提供するので、同じ仮想パッケージを持つ パッケージが
1つ以上システムにインストールされると、システム管理者は
優先パッケージを設定できます。関連するコマンドは
update-alternatives で、 Alternative コマンド, 第 6.5.3 節
で さらに詳しく述べられています。
Debian パッケージングシステムは、あるパッケージが機能したり、うまく 働くようにインストールされるべき他のパッケージを要求するという事実を 表現するために使われる依存性に関する宣言を操作します。
これらの用語の使用法についてのより詳しい情報は Debian パッケージング マニュアル と Debian ポリシーマニュアル にあります。
Depends と指定されたパッケージ全てを単に取得しますが、
Recommends や Suggests と指定された
パッケージを全て無視する apt-get に比べ、dselect
はより洗練した Recommends や Suggests
により指定されるパッケージ制御機能を有します。これらのプログラムは共に
現代的な形で APT をバックエンドとして使用します。
dpkg は、常に他のパッケージが依存しているパッケージを
先に設定します。しかしながら、dpkg
は通常ファイルを任意の順番で、依存性と関係なく解凍します。
(解凍とは、アーカイブファイルからのファイルの展開とそれらのファイルを
正しい場所に置くことから構成されます。)
しかしながら、もしパッケージが他のパッケージに Pre-Depends
している場合、Pre-Depends しているパッケージが解凍されていても、 その前に
Pre-Depends されているパッケージの解凍と設定が行われます。 [2]
この依存性の使用は最小限に保たれています。
パッケージステータスには "unknown", "install",
"remove", "purge", "hold" があります。 これらの
"want" フラグは利用者がそのパッケージをどう扱いたいかを示しています。
利用者は dselect の "Select" セクションでのアクション や
dpkg の直接起動によってこれを示すことができます。
それぞれの意味は以下の通りです。
パッケージを hold するには二つの方法があります。dpkg
を使う方法と、Woody から始まった APT を使う方法です。
dpkg では、パッケージ選択の一覧を
dpkg --get-selections \* > selections.txt
で書き出すだけです。それから書き出されたファイル
selections.txt を編集して hold したいパッケージの
行を変更します。例えば、
libc6 install
を
libc6 hold
にします。ファイルを保存して、
dpkg --set-selections < selections.txt
でdpkg データベースに再ロードしてください。又、hold したいパッケージ名 を知っている場合は、単に
echo libc6 hold | dpkg --set-selections
を実行するだけです。この手順は各パッケージファイルのインストール処理で パッケージを hold します。
同様の効果が dselect を通しても得られます。[S]elect 画面に 入って
hold したいパッケージの現在の状態を確認し、「=」キー (もしくは「H」キー)
を押下するだけです。変更は [S]elect 画面を終了するとすぐに反映します
Woody ディストリビューションにおける APT システムは Pin-Priority
を用いてアーカイブ取得処理中にパッケージを hold する新しいもう一つの機構
を持ちます。 http://www.debian.org/doc/manuals/apt-howto/
又は apt-howto パッケージのに、マニュアルページ
apt_preferences(5) をご覧ください。
ソースパッケージは source と呼ばれるディレクトリで
配布されています。手動でダウンロードできますし、
apt-get source foo
を使ってダウンロードもできます。 (このための APT の設定法については apt-get(8)
マニュアルページを 参照してください。) apt-get source foo
を使って取得することもできます (このための APT の設定法については
apt-get(8) を参照願います。)
パッケージ foo をソースからコンパイルするには、
foo_*.dsc, foo_*.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 節 をご覧ください。
新しいパッケージを作ることに関する詳細な情報は、 maint-guide
パッケージで得られる Debian メンテナ入門 又は http://www.debian.org/doc/manuals/maint-guide/
をご覧ください。
Debian の目標の一つは首尾一貫したアップグレード方針と安全な
アップグレード手順を提供することです。パッケージングシステムは
管理者に重要な変更について警告し、時々は管理者に決定を促します。
リリースノートも読むべきです。これは全ての Debian CD と一緒に
出荷されており、WWW でも http://www.debian.org/releases/stable/releasenotes
や http://www.debian.org/releases/testing/releasenotes
で利用可能です。
アップグレードを行う実際的なガイドは Debian パッケージ管理, 第 6 章 で供給されます。 本章では単に概要を供給します。まずはパッケージングツールから始めます。
dpkg
これはパッケージファイルの操作のための主要なプログラムです。 完全な説明は
dpkg(8) を読んでください。
dpkg にはいくつかの原始的な補助プログラムが付随します。
dpkg-deb: .deb ファイルを操作します。
dpkg-deb(1)
dpkg-ftp: 旧型のパッケージファイル取得コマンドです。
dpkg-ftp(1)
dpkg-mountable: 旧型のパッケージファイル取得用コマンドです。
dpkg-mountable(1)
dpkg-split: 大規模なパッケージを小さなファイルに分割します。
dpkg-split(1)
dpkg-ftp と dpkg-mountable は APT システムに
取って代わられました。
APT (the Advanced Packaging Tool) は Debian
パッケージングシステムの先進的なインターフェースであり、"apt-"
で始まる名前を持ついくつかのプログラムから 構成されています。
apt-get, apt-cache, と apt-cdrom
はパッケージ操作用のコマンドラインツールです。これらには dselect
や aptitude のような他のツールへのユーザ "バックエンド"
としても働きます。
より詳しい情報は、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 upgrade と apt-get dist-upgrade は
"Depends:" にリストされたパッケージのみを引っ張ってきますが、
"Recommends:" や "Suggests:"
にリストされたパッケージは無視します。 これを避けるには、dselect
を御使用ください。
dselect
このプログラムは Debian パッケージ管理システムへのメニュドリブンな
ユーザインターフェースです。最初のインストール時や大規模なアップグレード時
に特に役立ちます。dselect,
第 6.2.3 節 をご覧ください。
より詳しい情報は、install-doc パッケージをインストールし、
/usr/share/doc/install-doc/dselect-beginner.en.html や dselect
Documentation for Beginners を読んでください。
Debian システムにおける kernel (ファイルシステム) はファイルを使用中 でさえも、そのファイルの置き換えをサポートしてます。 現在のランレベルで起動されるようにパッケージが設定されている場合、 パッケージの更新時にパッケージにより供給されるサービスが再起動 されます。 Debian システムは起動中のシステムをアップグレードするのに シングルユーザモードを必要としません。
手動でパッケージファイルをディスクにダウンロードした場合、
(これは必ずしも必要ではありません。上に記述した dpkg-ftp または
APT の説明をご覧ください) パッケージをインストールした後、 システムから
.deb ファイルを削除できます。
APT を使っている場合、これらのファイルは /var/cache/apt/archives
ディレクトリにキャッシュされます。 これらをインストール後に削除 (apt-get
clean) できますし、
その後のインストール中のダウンロード時間を節約するため、 他のマシーンの
/var/cache/apt/archives ディレクトリにコピー してもかまいません。
dpkg
は展開、設定、削除またはパージされたパッケージの記録を取ります が、 (現在)
パッケージにそのような操作が行われている間に起こったターミナル上の
コマンドログを取っていません。
コマンドログを取る最もシンプルな方法は、dpkg,
dselect, apt-get などのセッションを
script(1)プログラム内で起動することです。
init プログラム
他の Unix ライク OS と同様に、Debian は init プログラムを
実行することによりブートを始めます。init 用の設定ファイル
(/etc/inittab) は、実行されるべき最初のスクリプトが
/etc/init.d/rcS であることを指定しています。
次に起きることは sysv-rc 又は file-rc
のどちらかがインストールされているかどうかに依存しています。 次に述べることは
sysv-rc がインストールされていることを
仮定しています。(file-rc には固有の /etc/init.d/rcS
スクリプトが含まれており、ランレベル毎に
起動されるサービスの種類を制御するために rc ディレクトリにある
シンボリックリンクの代わりにこのスクリプトが用いられます。)
sysv-rc パッケージにある /etc/init.d/rcS
ファイルはファイルシステムのチェックやマウント、モジュールの読み込み、
ネットワークサービスの開始、時計の設定などの初期化作業を行うために
/etc/rcS.d/ にあるスクリプト全てを起動します。
そして、互換性のために、/etc/rc.boot/ 下にあるファイル
(ファイル名に `.' が付くファイルを除く) も実行します。
後者のディレクトリ内のスクリプトは、通常システム管理者が使用するために
予約されており、パッケージがこのディレクトリにスクリプトを置くのは
時代遅れです。詳細は Debian ポリシーマニュアルの システムの初期化, 第 9.1 節 や System run
levels and init.d scripts をご覧ください。
ブートプロセス完了後、init は (/etc/inittab の
id 用のエントリにより与えられる) 標準のランレベルで
起動されるように設定された全てのサービスを起動します。 標準のランレベルは
/etc/inittab 中の id エントリ により与えられます。
Debian は id=2 となっています。
Debian は次のランレベルを使用しています。
ランレベル 7, 8, 9 も使用可能ですが、パッケージがインストールされる時に これらの rc ディレクトリにはあまり起動スクリプトがリンクされません。
ランレベルを切替えるには telinit コマンドを用います。
あるランレベルに入ると、/etc/rcrunlevel.d/
にある全てのスクリプトが実行されます。 スクリプトの最初の
1文字はスクリプトの起動方法 を決定します。 K
で始まる名前のスクリプトは、引数 stop を取って 起動されます。
S で始まる名前のスクリプトは、引数 start を取って
起動されます。
これらのスクリプトは名前のアルファベット順で起動されます。それゆえ、
"stop" スクリプトは "start" スクリプトより前に起動され、
K や S に続く 2桁の数字はスクリプトの起動順序
を決定します。
実は、/etc/rcrunlevel.d/ ディレクトリにある
スクリプトは、/etc/init.d/ にあるスクリプトの
単なるシンボリックリンクです。 これらのスクリプトは引数として
"restart" や "force-reload" という
引数も受け取ります。システムのブート後にサービスを再起動
するためや、設定ファイルを再読み込みさせるためにこれらの引数を使えます。
例えば、
# /etc/init.d/exim4 reload
のように使います。
ランレベルをカスタマイズするのは一歩進んだシステム管理者の仕事です。 ほとんどのサービスの場合、次に示すアドバイスが適用できます。
ランレベル R でサービス service を有効にするには、
ターゲットを ../init.d/service として
シンボリックリンク
/etc/rcR.d/Sxyservice
を作成します。 シーケンス番号 xy
はパッケージがインストールされた時の
サービスに割り当てられたシーケンス番号と一致させてください。
サービスを無効にするには、名前が S で始まるのではなく K で始まるようにシンボリックリンクをリネームし、 シーケンス番号を 100-xy にします。
これらの目的には sysv-rc-conf や ksysv
のようなランレベルエディタを使うのが便利です。
特定のランレベルディレクトリにあるサービスのシンボリックリンクを
リネームするのではなく削除することも可能です。
これはサービスを無効にしますが、sysv-rc の
初期化システムに関する限りに "floating" な状態に保ちます。
ランレベルを変更すると、サービスは起動されませんし、
停止もされませんが、起動しているかそうでないかにかかわらずそのままに
保たれます。 しかしながら、そのような浮いた状態にされたサービスは、
サービスを提供するパッケージがアップグレードされた場合、
アップグレード前に起動されているかにかかわらず起動されてしまうことに
注意してください。 これは現在の Debian システムの欠点として良く知られています。
又、ランレベル 0 と 6 では K で始まるサービスのシンボリックリンク
を保持すべきであることに注意してください。
このサービスに対するシンボリックリンクを全て削除してしまうと、
アップグレードの際、出荷時の標準の状態にサービスを提供するパッケージが
シンボリックリンクを回復させてしまいます。
/etc/rcS.d/ にあるシンボリックリンクにあらゆる変更を加える
ことは推奨できません。
Debian はシステムを壊さずにシステム管理者の希望を満たすためのいくつかの手段 を提供します。
dpkg-divert, dpkg-divert コマンド, 第
6.5.1 節 参照。
equivs, equivs
パッケージ, 第 6.5.2 節 参照。
update-alternative, Alternative コマンド, 第 6.5.3 節
参照。
make-kpkg は多くのブートローダに対応します。
make-kpkg(1) および Debian 標準の方法, 第 7.1.1 節
参照。
/usr/local/ 以下のファイルはシステム管理者のものであり、 Debian
は一切触りません。 /etc 以下のほとんどの ファイルは
conffiles であり、 Debian
はシステム管理者が明示的に要求しない限りアップグレード時に 上書きしません。
Debian システムは国際化されており、コンソール上ならびに X 上で 多種の言語の文字を表示し、入力するためのサポートを供給します。 たくさんのドキュメント、マニュアルページ、そしてシステムメッセージが 翻訳されており、翻訳されている言語は増加し続けています。インストール中、 Debian はユーザにインストール言語 (そして時々はローカル言語変数 )の選択を 促します。
あなたが必要な言語の機能全てをインストールしたシステムがサポート していない場合、又はあなたの言語をサポートするために言語の変更や、 異なるキーボードのインストールが必要な場合、ローカライゼーション (l10n), 第 9.7 節 をご覧ください。
Debian での Linux kernel, 第 7 章 をご覧ください。
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 を
含める必要性が発生します。
カスタム 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 にあります。
grub や loadlin
のような代替ブートローダを使いたい場合、 コンパイルした Linux kernel
bzimage を他の場所 (例えば、/boot/grub や MS-DOS
パーティション) にコピーしましょう。
カスタムブートフロッピを作成する作業は、Potato 以前の Debian FTP アーカイブの
admin セクションにある Debian パッケージ
boot-floppies により、大きな手助けが得られます。
本パッケージにあるシェルスクリプトはブートフロッピを syslinux
フォーマットで作成します。これらは MS-DOS フォーマット され、直接 Linux
(又はsyslinux.cfg で定義された他のオペレーション システム)
をブートするようにマスターブートレコードが変更されたフロッピです。
本パッケージの他のスクリプトは緊急 root ディスクを作成し、base ディスクの
再製作さえできます。
詳細は boot-floppies パッケージをインストールした後、
/usr/doc/boot-floppies/README ファイルをご覧ください。
Debian の modconf パッケージはモジュールの設定をカスタマイズする
ために使用できるシェルスクリプト (/usr/sbin/modconf) を供給
します。このスクリプトはメニュベースのインターフェースを表示し、システムの
ローダブルデバイスドライバに関する詳細に対してユーザを促します。 その応答は
/etc/modules.conf や /etc/modules
をカスタマイズするのに使用されます (これらにはブート時にロードされる
モジュールがリストされています)。
カスタム kernel の構築をサポートするために得られる (新しい)
Configure.help ファイルと同様に、modconf
パッケージには
モジュールそれぞれに対して適切な引数についての詳細な情報を供給する
(/usr/share/modconf/ にある) ヘルプファイルが付属します。 用例は
モジュール化された 2.4 kernel, 第
7.2 節 をご覧ください。
kernel-image-NNN.prerm スクリプトは現在起動している
kernel が削除しようとしている kernel と同じかどうかチェックします。それゆえ、
使わない kernel image パッケージを安全に次のコマンドを用いて削除できます。
# dpkg --purge --force-remove-essential kernel-image-NNN
(もちろん、NNN を削除したい kernel のバージョンとリビジョンに 置き換えます。)
Debian リファレンス
CVS, 2005年 ４月 3日 月曜日 22時59分00秒 UTC時間osamu@debian.orgtsuno@ngy.1st.ne.jp