[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ 次のページ ]
本章は非開発者のために Debian システムの基礎的な情報を供給します。 信頼できる情報が欲しい場合は、次を参照してください。
Debian ポリシーマニュアル
Debian デベロッパーリファレンス
Debian ニューメンテナーズガイド
参考文献, 第 15.1 節 にリストされています。
あまり詳しくない "how-to" 的な説明を探している場合、 Debian パッケージ管理, 第 6 章 や他の該当する章にすぐ飛んでください。
本章は "Debian FAQ" から取られた文書に基づき、通常の Debian システム管理者が始められるように大規模な再構成を行いました。
Debian 用にパッケージングされているソフトウェアは Debian mirror site
のそれぞれのいくつかの ディレクトリツリーの一つから FTP 並びに HTTP
経由で取得できます。
次のディレクトリは 各 Debian ミラーサイトの debian
ディレクトリの下で見つかります。
dists/:
このディレクトリには "distributions" が含まれており、これは 現在
Debian release および pre-release で得られるパッケージへの
標準的なアクセス手段として使用されます。いくつかの古いパッケージや
Contents-*.gz 、そして Packages.gz も
まだここにあります。
pool/:ここは Debian release および pre-release の全パッケージ が物理的に存在する場所です。
tools/:ブートディスク作成、ハードディスクのパーティショニング、 ファイル圧縮/解凍、そして Linux のブート用の DOS ユーティリティが ここにあります。
doc/:FAQ, バグ報告システム指示書などの基本的な Debian に関する 文書がここにあります。
indices/:Maintainers ファイルや override ファイルがここにあります。
project/:主に開発者のみ必要なものです。例えば、
project/experimental/:本ディレクトリにはまだ開発中であり、まだ α テスト段階の パッケージやツールが含まれます。ユーザはここにあるパッケージを 使用するべきではありません。なぜなら、最も経験を積んだ人でさえも 危険で害を及ぼす可能性があるからです。
project/orphaned/:古いメンテナにより「みなしご化」され、ディストリビューションから なくなったパッケージです。
通常 dists ディレクトリには 3種類の Debian
ディストリビューションが存在します。これらは stable.
testing そして unstable と呼ばれます。 時々
frozen
も存在します。(現在はfrozenはtesting
の開発ステージのひとつです。)各ディストリビューションは dists
ディレクトリにある、コードネームが付いた
実際のディレクトリのシンボリックリンクとして定義されています。
stable ディストリビューション, Debian Sarge (3.1r0) 用のパッケージ
エントリは stable (sarge/ への シンボリックリンク)
ディレクトリに記録されています。
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 Etch のパッケージ
エントリは unstable でしばらくテストを受けた後に
testing (etch/ への シンボリックリンク)
ディレクトリに記録されます。 上に挙げた場所に加え、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 ディストリビューションの最新バグステータスはこれらのサイト で報告されています。
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 に入ります。
パッケージのリリースを遅らせたり、リリース全体を止めてしまう frozen ディストリビューションのバグを記録し続けています。 バグ総数が最大許容数を下回ったら、frozen ディストリビューション は stable になり、リリースされます。そして以前の stable ディストリビューションは obsolete になります。(そして archive に移動します)
sarge/ や etch/ などの、dists
ディレクトリにある物理的に存在するディレクトリ名は、 単なる
"コードネーム" です。Debian ディストリビューションが開発段階に
あるとき、バージョン番号を持ちませんが、その代わりコードネームを持ちます。
これらのコードネームの目的は、Debian ディストリビューションのミラーリングを
より簡単に行うためです。(もし真のディレクトリ名unstableが
突然stable に変わると、不必要に多くの
ダウンロードを再び行わなくてはならなくなります)
現在、stable は sarge/ の、 testing は
etch/ のシンボリック リンクです。これは Sarge
が現在の stable ディストリビューションであり、Etch が現在の
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 作の映画 トイストーリー の キャラクター名から取られていました。
Buzz (Buzz Lightyear) は宇宙飛行士です。
Rex はチラノザウルスです。
Bo (Bo Peep) は羊飼いの娘です。
Hamm Hamm は豚の形の貯金箱です。
Slink (Slinky Dog) おもちゃの犬です。
Potato はもちろん、ミスターポテトです。
Woody はカウボーイです。
Sarge はグリーンプラスティックアーミーのリーダーです。
Etch (Etch-a-Sketch) はおもちゃの黒板です。
Sid は隣に住んでいる、おもちゃを壊す男の子です。
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 のような
プログラムにより使用される索引ファイルのために使われています。
新しい apt や多分古い dpkg-ftp
はシームレスな処理を行うので、通常は
これらのことを心配する必要はありません。詳細を知りたい場合は、 RFC:
implementation of package pools をご覧ください。
昔 Sid は存在していませんでした。Debian archive サイトは大きな欠陥を
1つ持っていました。アーキテクチャが最新の unstable
に作られると、ディストリビューションが新しい stable になった時に
それがリリースされるという前提がありました。このケースにあてはまらない
多くのアーキテクチャにとって、リリース時にこれらのディレクトリが移動
しなければならないという結果となりました。この移動が膨大なバンド幅を
消費するため、これは実際的ではありません。
アーカイブ管理者はこの問題に数年間取り掛かり、sid と
呼ばれる特別なディレクトリに未リリースのアーキテクチャのためのバイナリを置く
ことにより問題を解決してきました。未リリースのアーキテクチャが最初にリリースされる
場合、最新の 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つのタイプがあります。
バイナリパッケージ。これには実行ファイル、 設定ファイル、 man
ページと info ページ、著作権情報やその他の文書が 含まれます。これら
のパッケージは Debian 固有のアーカイブ形式で 配布されています。(Debian パッケージのフォーマット, 第 2.2.2 節参照) また
.deb という ファイル拡張子を持っています。バイナリパッケージは Debian
ユーティリティ dpkg を用いて展開できます。詳細は dpkg
の マニュアルページに記載されてあります。
ソースパッケージ。ソースパッケージの解説が書かれた
.dsc ファイル
(このファイルには以下のファイルの名前も書かれています)
や、修正されていないオリジナルのプログラムソースが gzip で圧縮された tar
フォーマット形式で含まれている .orig.tar.gz ファイ ル、 通常
Debian 固有の変更を記した .diff.gz ファイルから構成
されています。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 アーカイブファイルには、 実行プログラム一式や関連するプログラムのセットに関係する実行ファイルや、 ライブラリ、ドキュメントが含まれています。通常、Debian アーカイブファイルは ファイル名の最後に .deb が付いています。 [1]
Debian バイナリパッケージフォーマットの内部仕様は deb(5)
マニュアルページに解説されています。 このフォーマットは (Debian
のメジャーリリースの間で) 変更されることが あるので、.deb
ファイルを操作する時は必ず dpkg-deb(1) を使って下さい。
少なくても 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)"
セクションの一部となっています。
個々のファイルは以下の通りです。
このスクリプトは、パッケージが Debian アーカイブ (.deb/) ファイルからアンパックされる前に実行されます。パッケージがインストールか アップグレードし終わる ("postinst" スクリプトが正常に実行された後) まで、多くの"preinst" スクリプトの中で、更新されるパッケージのために サービスが停止されるようになっています。
このスクリプトの典型的な仕事は、Debian アーカイブファイル (.deb/) からアンパックされたら、それに必要な設定をすべて完了させる ことです。 "postinst" スクリプトのよくある動作として、ユーザに入力を求め、 既定値を受け入れるなら後戻りしてこのパッケージを環境に沿うように 再設定することを忘れないように警告を表示します。 新しいパッケージがインストールされるかアップグレードされると、 多くの "postinst" スクリプトはサービスを開始または再開するのに 必要なコマンドをすべて実行します。
このスクリプトは、典型的にはパッケージに関連したあらゆる デーモンを停止します。これはパッケージに関連したファイルを 削除する前に実行されます。
このスクリプトは、典型的にはパッケージに関連したリンクや 他のファイルを修整したりパッケージが作成したファイルを削除したりします。 (仮想パッケージ, 第 2.2.7 節 も参照。)
現在、制御ファイルは全て /var/lib/dpkg/info/
に置かれています。パッケージ foo に関係するファイルは
"foo" で始まる 名前を持ち、"preinst" や
"postinst" などの適当なファイル拡張子を持ちます。
このディレクトリにある foo.list というファイルは、 パッケージ
foo によってインストールされたファイルがすべて リストされています
(これらのファイルの存在場所は dpkg が
内部に持っていることに注意して下さい。存在場所を頼りにしないほうが
いいでしょう)。
それぞれの Debian パッケージには、パッケージ管理システムの助けとして、 ディストリビューション保守担当者が 優先度 を割りあてています。 優先度には以下のものがあります。
Required (要求) パッケージはシステムを正しく 動作させるために必要なパッケージです。
システムの欠陥を修復するのに必要なツールをすべて含みます。
これらのパッケージを消去してはいけません。システムがすっかり破壊され、 復旧
するために dpkg を使うことすら恐らくできなくなります。 Required
パッケージだけのシステムは恐らく使いものになりませんが、
システム管理者が起動したり他のソフトウェアをインストールするだけの
機能はあります。
Important (重要) パッケージはどのような Unix ライクなシステムにもあるべきパッケージです。
Required 以外のパッケージで、無いとシステムがうまく動かなかったり 不便だったりするものにこの優先度がつけられています。これには Emacs や X11、TeX 他の巨大なアプリケーションは含まれていません。 ここのパッケージは、素のインフラストラクチャを構成するだけです。
Standard (標準) パッケージはどんな Linux システム にも標準的なパッケージで、手頃な小ささですが機能が限定されすぎていない キャラクタモードシステムを含んでいます。
これはユーザが何も指示しなかったらデフォルトでインストールされます。 多くの巨大なアプリケーションは含まれませんが、Emacs はあります (これはアプリケーションというよりも多くのプログラムのための インフラストラクチャの一部です) し、TeX と LaTeX の手頃なサブセットが (X なしで稼動可能な部分なら) 含まれています。
Optional (任意) パッケージにはそのパッケージが 何なのかを知らなかったり、そのパッケージを使わなければならない特別な 要求がなかったりしてもインストールしてかまわないパッケージが含まれています。
これには X11 や TeX 配布物全体、多くのアプリケーションが含まれています。
Extra (付録) パッケージはより高い優先度を持つ パッケージと衝突するか、そのパッケージがどういうものか知っているか、 あるいは "任意" というには相応しくない特殊な要求を持っているパッケージです。
パッケージの説明にある "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 パッケージングシステムは、あるパッケージが機能したり、うまく 働くようにインストールされるべき他のパッケージを要求するという事実を 表現するために使われる依存性に関する宣言を操作します。
A を使うために B が絶対インストールされなければならない場合、 パッケージ A はパッケージ B に Depends すると表現します。 いくつかの場合、A は B だけでなく、B の特別なバージョンに依存 します。この場合、バージョンの依存性は、A がある指定したバージョン 以降のバージョンの B に依存するという意味で、通常下限を表します。
ほとんどのユーザは B により供給される機能も持たない A を 欲しいとは思わないとパッケージのメンテナが判断した場合、 パッケージ A はパッケージ B を Recommends すると 表現します。
A に関係し、A の機能を強化するファイルが B に含まれている場合、 パッケージ A はパッケージ B を Suggusts すると表現します。 同じ関係は、パッケージ B がパッケージ A を Enhances すると表現します。
B がシステムにインストールされていると A が適切に動作しない場合、 パッケージ A はパッケージ B と Conflicts すると 表現します。"Conflicts" ステータスはたびたび "Replaces" と置き換えられます。
B によりインストールされるファイルが A にあるファイルにより 削除あるいは上書きされる場合、パッケージ A はパッケージ B を Replaces すると表現します。
B の全てのファイルと機能が A にも組み込まれている場合、 パッケージ A はパッケージ B を Provides すると 表現します。
これらの用語の使用法についてのより詳しい情報は Debian パッケージング マニュアル と Debian ポリシーマニュアル にあります。
Depends と指定されたパッケージ全てを単に取得しますが、
Recommends や Suggests と指定された
パッケージを全て無視する apt-get に比べ、aptitudeや
dselect は、Recommends や
Suggests
により指定されるより洗練されたパッケージ制御機能を有します。これらのプログラムは、共に現代的な形で
APT をバックエンドとして使用します。
dpkg は、常に他のパッケージが依存しているパッケージを
先に設定します。しかしながら、dpkg
は通常ファイルを任意の順番で、依存性と関係なく解凍します。
(解凍とは、アーカイブファイルからのファイルの展開とそれらのファイルを
正しい場所に置くことから構成されます。)
しかしながら、もしパッケージが他のパッケージに Pre-Depends
している場合、Pre-Depends しているパッケージが解凍されていても、 その前に
Pre-Depends されているパッケージの解凍と設定が行われます。 [2]
この依存性の使用は最小限に保たれています。
パッケージステータスには "unknown", "install",
"remove", "purge", "hold" があります。 これらの
"want" フラグは利用者がそのパッケージをどう扱いたいかを示しています。
利用者は dselect の "Select" セクションでのアクション や
dpkg の直接起動によってこれを示すことができます。
それぞれの意味は以下の通りです。
unknown - インストールするかどうかユーザが 表明していないパッケージ
install - ユーザがインストールまたはアップグレード したいパッケージ
remove - 削除はしたいが、既存の設定ファイルは 一つも削除したくないパッケージ
purge - 設定ファイルを含め、完全に削除してしまう パッケージ
hold - 処理はしない、つまりどのような状態 であれ現在の状態で現在のバージョンを維持するパッケージ
パッケージを 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 はありません)。
これらを入手し、pkg-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 のような他のツールへのユーザ "バックエンド"
としても 働きます。
現在、aptitudeは、システム維持のための推奨ツールです。
より詳しい情報は、apt パッケージと aptitude
パッケージをインストールして、 aptitude(8),
apt-get(8), apt-cache(8), apt-cdrom(8),
apt.conf(5), sources.list(5),
apt_preferences(5) を読んでください。
もう一つの情報源としては、 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 は次のランレベルを使用しています。
1 (シングルユーザモード),
2 から 5 (さまざまなマルチユーザモード),
0 (システムを停止), そして
6 (システムをリブート)。
ランレベル 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) および Kernel (再)構築, 第 7.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(1) 全体と 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 にあります。
Debian の modconf パッケージはモジュールの設定を
カスタマイズするために使用できるシェルスクリプト
(/usr/sbin/modconf) を供給します。このスクリプトはメニュベースの
インターフェースを表示し、システムのローダブルデバイスドライバに関する詳細に
対してユーザを促します。 その応答は /etc/modules.conf や
/etc/modules をカスタマイズするのに使用されます
(これらにはブート時にロードされる モジュールがリストされています)。
カスタム kernel の構築をサポートするために得られる (新しい)
Configure.help ファイルと同様に、modconf
パッケージにはモジュールそれぞれに対して適切な引数についての詳細な情報を
供給する (/usr/share/modconf/ にある) ヘルプファイルが付属します。
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 リファレンス
CVS, 2007年 １月 18日 木曜日 11時54分01秒 UTC時間osamu#at#debian.orgtsuno#at#ngy.1st.ne.jp