本章は非開発者のために Debian システムの基礎的な情報を供給します。 信頼できる情報が欲しい場合は、次を参照してください:
References, 第 15.1 節 にリストされています。
あまり詳しくない "how-to" 的な説明を探している場合、 Debian パッケージ管理, 第 6 章 や他の該当する章にすぐ飛んでください。
本章は "Debian FAQ" から取られた文書に基づき、通常の Debian システム管理者が始められるように大規模な再構成を行いました。
Debian 用にパッケージングされているソフトウェアは Debian mirror site
のそれぞれのいくつかの ディレクトリツリーの一つから FTP 並びに HTTP
経由で取得できます。
次のディレクトリは 各 Debian ミラーサイトの debian
ディレクトリの下で見つかります:
dists/
: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/
: このディレクトリには、
特別な著作権要求に配布者が細心の注意を払う必要があるような、
配布制限されたパッケージが含まれます。
例えば、いくつかのパッケージは商用配布を禁止するライセンスを持っています。 また、再配布可能ですが、実はシェアウェアでフリーソフトでは ないパッケージもあります。どのような再配布物 (CD-ROM など )に含めるのであれ、 それぞれのパッケージの使用許諾を事前に調べておき、できるだけ交渉して おかなければなりません。
stable/contrib/
: このディレクトリには DFSG-free でそれら自体は
自由に再配布可能 ですが、 フリーに再配布
できない ため、non-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://ftp-master.debian.org/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
Problems
web ページで 報告されています。
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 ディストリビューションですので、usstable/
は
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"。
いままではコードネームは 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
(Debian システムのアップグレード手順, 第 2.3.1 節
参照) はシームレスな処理を行うので、通常はこれらのことを心配する
必要はありません。詳細を知りたい場合は、RFC:
implementation of package pools
をご覧ください。
昔 Sid は存在していませんでした。Debian archive
サイトは大きな欠陥を一つ持っていました: アーキテクチャが最新の
unstable
に作られた時、 ディストリビューションが新しい
stable
になった時にそれがリリースされるという前提がありました。このケースにあてはまらない多くのアーキテクチャにとって、リリース時にこれらのディレクトリが移動しなければならないという結果となりました。この移動が膨大なバンド幅を消費するため、これは実際的ではありません。
アーキテクチャ管理者はこの問題に数年間取り掛かり、sid
と
呼ばれる特別なディレクトリに未リリースのアーキテクチャのためのバイナリを置く
ことにより問題を解決しました。未リリースのアーキテクチャが最初にリリースされる
場合、最新の stable/
に対し sid/
がリンク
されました。そして、それ以降は通常どおり unstable
内に
バイナリが作成されました。
Woody ディストリビューションの開発中にパッケージプールを (pool
ディレクトリ, 第 2.1.10 節 参照)
発明したことにより、バイナリパッケージは
ディストリビューションに依らずにプール内の標準的な場所に保存され始めました。
それゆえ、ディストリビューションのリリースを行っても、もはやミラー時に
大きなバンド幅を消費しません。(しかし、開発過程を通し、緩やかなバンド幅
消費が発生します。)
incoming/
にパッケージをアップロードする
パッケージのアップロードはそれらが本当に Debian 開発者からのものかを
検査した後に http://incoming.debian.org/
にまず置かれます。 (そしてそれがノンメンテナアップロード (NMU)
の場合は、DELAYED
サブディレクトリに置かれます。)
一日に一度、それらは 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.9 節
に記述された手順により、パッケージを手動で構築する方法を習得できます。
公式には Debian システムの一部では無い contrib
や
non-free
ディレクトリにあるパッケージのソースコードは
入手できるかもしれませんし、できないかもしれません。
一般にパッケージには関連するコマンドや機能を実装するのに必要な ファイルすべてが含まれています。Debian パッケージには二つのタイプがあります:
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_バージョン番号-Debian リビジョン番号.deb。
ここで、foo はパッケージ名の代わりであることに注意して下さい。 照会するためには、以下の方法で特定の Debian アーカイブファイル (.deb ファイル ) に関係のあるパッケージ名を調べることができます:
VVV の部分はバージョン番号を示し、上流の開発者により指定されます。 この部分には標準がありません。バージョン番号は "19960513"や "1.3.8pre1" のようにフォーマットが異なっているかもしれません。
RRR の部分は Debian のリビジョン番号で、Debian の開発者
(か自分自身のためにパッケージをビルドすることにした個人ユーザ) が決定します。
この番号は Debian パッケージのリビジョンレベルに対応します。
したがって、リビジョンレベルが新しくなると、普通、Debian の Makefile
(debian/rules
) や Debian 制御ファイル
(debian/control
) 、インストールまたは削除スクリプト
(debian/p*
)、
パッケージが利用する設定ファイルなどに変更があったことを意味します。
ユーザが設定可能なファイルの保存は Debian の "conffile" 機構を通して
行えます。ユーザ設定ファイルは (通常 /etc/
に置かれる) Debian
パッケージシステム内の conffile
に指定されます。
パッケージ管理システムはパッケージのアップグレード時にこれらのファイルを
上書きしないことを保証します。
さまざまな Debian パッケージに所属するファイルを修正せずにシステムの 設定を行うことが可能です。通常それらが "conffile" な場合でさえも修正 しないのは良い考えです。これにより高速でスムーズな更新作業が保証されます。
アップグレード中に保持するファイルを正確に決めるには、次のコマンドを 起動します:
dpkg --status package
そして "Conffiles:" の下を見ます。
Debian conffile
ファイルの内容の特徴は Debian ポリシーマニュアル
section 11.7 (References, 第 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 はこのようなしくみを提供するので、同じ仮想パッケージを持つ
パッケージが一つ以上システムにインストールされると、システム管理者は
優先パッケージを設定できます。関連するコマンドは
update-alternatives
で、 Alternative コマンド, 第 6.5.3 節
で さらに詳しく述べられています。
Debian パッケージシステムはパッケージ "依存性" に幅を持っています。 あるシステム上でプログラム A がプログラム B の存在からどれくらい独立して 動作させられるかを (フラグ一つで) 表示するよう設計されています:
これらの用語の使用法についてのより詳しい情報は Debian パッケージング マニュアル と Debian ポリシーマニュアル にあります。
単に depends と指定されたパッケージ全てを取得しますが、
recommends や suggests と指定された
パッケージを全て無視する apt-get
に比べ、dselect
はより洗練した recommends や suggests
により指定されるパッケージ制御機能を有します。これらのプログラムは共に
現代的な形で APT をバックエンドとして使用します。
"Pre-depends" は特別な依存関係です。通常のパッケージの場合、
dpkg
はアーカイブファイル (すなわち .deb ファイル)を
依存するファイルがシステム上にあるかにどうかに係わらず独立に展開します。
展開は基本的に dpkg
がファイルシステム上にインストールされる
アーカイブファイルからファイルを取り出し、ある場所に置くことを意味します。
それらのパッケージがシステム上にある他のパッケージの存在に
依存している場合、dpkg
は他のパッケージがインストールされるまで、 (その "configure"
動作を実行せずに) インストールの完了を拒絶します。
しかしながら、あるパッケージは依存性が解決されるまで、dpkg
が
パッケージファイルの展開さえ拒否します。
そのようなパッケージは他のパッケージの存在に "pre-depends" する
と言われます。Debian プロジェクトは、パッケージを展開する
順番が非常に重要であった a.out フォーマットから
ELF フォーマットへの
システムの安全な更新をサポートするためにこの機構を導入しました。
この方法が有効な大規模なアップグレード状況もあります。例えば、"required"
優先度を持ち、libc に依存するパッケージを更新する場合などです。
先の項目と同様に、本機構に関するより詳しい情報は パッケージマニュアル にあります。
パッケージステータスには "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 データベースに再ロードしてください。又、ホールドしたいパッケージ名 を知っている場合は、単に
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 節 にも簡潔な説明があります。
ソースパッケージは 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 章 で供給されます。 本章では基本的な手順を記述します。
単純に Debian アーカイブに匿名 ftp または wget
をかけ、次に
ディレクトリをよく調べて、欲しいファイルを見つけ、それを取ってきます。 最後に
dpkg
を使ってそのファイルをインストールします。
(たとえシステムが稼動していても、 dpkg
はアップグレードする
必要のあるファイルをきちんとインストールしてくれることに注意してください。)
しかし、あるパッケージをアップグレードしようとした時、他のパッケージも
アップグレードするように要求される場合があります。この場合、
指示されたアップグレードを行うまで、あるいは行わなければ、
希望するパッケージのアップグレードは失敗してしまいます。
この方法はあまりにも時間がかかり過ぎると多くの人が感じるでしょう。 というのも Debian は急速に進化しているからです。通常、一週間に 1 ダース 以上もの新しいパッケージがアップロードされています。 新しいメジャーリリースの直前にはもっと増えます。このような大変な アップグレード作業を自動化してくれるプログラムを使いたいという人が 多くいます。このためにいくつかの専用のパッケージが利用できます
Debian
パッケージ管理システムには二つの目的があります:パッケージファイル自身の操作と
Debian アーカイブからのパッケージファイルの取得です。dpkg
は前者の作業を行い、APT や dselect
は後者です。
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 (ファイルシステム) はファイルを使用中で な場合でさえも、そのファイルの置き換えをサポートしてます。
ブート時にデーモンを起動したり、kernel のランレベルが変更された時
(例えば、マルチユーザからシングルユーザにとか、"halt"
などに変更した時) にデーモンを停止したりするために用いる
start-stop-daemon
と呼ばれる
プログラムも提供しています。同じプログラムは、デーモンを含む新パッケージを
インストールした時に、起動中のデーモンを停止したり必要な場合に
デーモンを再起動するため、インストールスクリプトにより使用されます。
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
であることを指定しています。 このスクリプトは
/etc/rcS.d/
下にあるスクリプトをそのファイル
拡張子に応じて、読み込むか、サブプロセスを fork することにより
初期化処理を実行します。その初期化処理には、ファイルシステムのチェックやマウント、モジュールの読み込み、ネットワークサービスの開始、時計の設定などが含まれます。そして、互換性のために、/etc/rc.boot/
下にあるファイル (ファイル名に `.' が付くファイルを除く)
も実行します。後者のディレクトリ内のスクリプトは通常システム管理者が使用するために予約されており、パッケージがこのディレクトリにスクリプトを置くのは時代遅れです。詳細は
Debian ポリシーマニュアルの システムの初期化, 第 9.1 節 や System
run levels and init.d scripts
をご覧ください。
ブートプロセス完了後、init
は (/etc/inittab
の
id 用のエントリにより与えられる) 標準のランレベルにより指定された
ディレクトリ内の全ての起動スクリプトを実行します。 全ての 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 デーモンにシグナルを送ります。
Debian はブートプロセスをカスタマイズするのに BSD スタイルの rc.local ディレクトリを使用しません。その代わり、カスタマイズのために 次に述べる機構を供給します。
システムが起動時又は特定の (System V) ランレベルにおいて foo というスクリプトを実行する必要があると想定します。そのとき、システム管理者が すべきなのは次の通り:
/etc/init.d/
ディレクトリに
入れる。
update-rc.d
を適切な引数を使って
起動し、(コマンドラインで指定した) rc?.d ディレクトリ
と /etc/init.d/foo
のリンクを設定する。 ここで、? は
System V ランレベルのうちのどれかに対応する 0 から 6 までの番号。
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
の標準ランレベルを参照します。引数 19 は foo が番号
20 以上を持つスクリプト よりも前に実行されることを保証します。
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 は ユーザにインストール言語 (そして時々はローカル言語変数 )の選択を促します。
あなたが必要な言語の機能全てをインストールしたシステムがサポートしていない場合、又はあなたの言語をサポートするために言語の変更や、異なるキーボードのインストールが必要な場合、国際化, 第 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
パーティション) にコピーしましょう。
カスタムブートフロッピを作成する作業は、通常 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 レファレンス
1.07-2, 2004年 4月 11日 日曜日 08時00分07秒 UTC時間osamu@debian.org
tsuno@ngy.1st.ne.jp