ARMA
           ARMA Net           製品とサポート           通信販売           会社概要           求人情報       
マニュアル目次

はじめに

第1章 ARMA とは

第2章 インストール
2.1 インストールの準備
2.2 インストール
2.3 ORCAの設定
2.4 データ DVD-R/CD-R の作成
2.5 Windows 下での ARMA
  のブート CD-R の作成

2.6 ブートUSBの作成
2.7 NVIDIA ドライバの設定
2.8 AMD(ATI) ドライバの設定
2.9 無線 LAN の設定

第3章 システムの設定
3.1 管理ツール
3.2 パッケージ管理
3.3 マウントとアンマウント
3.4 デバイスファイル
3.5 ブートローダ
3.6 TCP/IPネットワーク
3.7 基本的なネットワークの設定
3.8 ssh による暗号化通信
3.9 X Window System
3.10 時刻合わせの設定

第4章 アプリケーション
4.1 ログインと基本的なコマンド
4.2 シェル
4.3 テキスト処理ツール
4.4 テキストエディタ
4.5 WWWブラウザ
4.6 電子メール
4.7 ダウンロードコマンド
4.8 音楽系ツール
4.9 DVD-RW/CD-RW の
  パケットライティング

4.10 動画再生環境の構築
4.11 システム管理上のヒント

第5章 アップグレード
5.1 ARAM2.2/2.1 から ARMA3.0
  へのアップグレード

5.2 ARMA2.1(ORCA版) から
  ARMA3.0 へのアップグレード


第6章 プレインストール
6 プレイストールのセットアップ



※プリントされた本マニュアルは
通信販売よりご購入いただけます。
(印刷はモノクロとなります。また
HTML版・オンライン版と若干バージ
ョンが異なる場合がございます。)
 
3.2 パッケージ管理
 
 
3.2.1 パッケージ…の説明の前に
 
 突然ですが、「パッケージ」とは何かを考えるためにソフトウェアをごはんに例えてみましょう。使える状態のソフトウェアをほかほかごはんだとすると、「パッケージ」はちょうど冷凍されてパックに入ったごはんに相当します。
 しかし、パックごはんが出てくるまでは、ごはんはお米を炊いて食べるものでした。もちろん、炊いただけで炊飯器から直接食べるわけにはいきませんので、しゃもじで茶碗によそわなければいけません。ソフトウェアの世界でもこのモデルは同じで、お米は「ソースファイル」、炊くことは「コンパイル」、よそうことは「インストール」に相当します。
 お米から作れば、とぎ方や水加減や炊き方次第でいくらでも自分好みのごはんができます。しかし、毎度毎度ごはんを炊くのは少々面倒ですし、水加減を失敗して食べられないごはんができてしまうかもしれません。その点、パックごはんは出来合いですがチンすれば誰でもすぐに食べられ、忙しい人にはとても重宝するものです。
 それでは、たとえ話はここまでにして、実際のソフトウェアのパッケージがどのようなものであるかを説明していきましょう。
 
 
3.2.2 パッケージ
 
 Linux に限らず、多くの OS は静的な情報をファイルという単位で管理しています。しかし、実際に使う 1 本のソフトウェアは 1 つのファイルではなく、あちこちのディレクトリに分散した多くのファイルの集合体です。例えばごく小さなソフトウェアにも、以下のようなファイルがあります。
 
/usr/bin/hoge
実行ファイル
/usr/lib/libhoge.so
共有ライブラリファイル
/usr/man/man1/hoge.1.gz
オンラインマニュアル
/usr/share/doc/hoge/README
添付文書 (ReadMe)
 
 このため、ファイル単位でソフトウェアを管理するには、ソフトウェアをインストールしたり削除したりするたびにあちこちのディレクトリでファイル操作をしなくてはなりません。大規模なソフトウェアでは数千ものファイルが数十のディレクトリに散らばっているので、このファイルを過不足なく削除することはかなり面倒な作業になります。もちろん、ファイルを削除し忘れれば、ディスクを浪費するばかりでなくシステムの見通しも悪くなってしまいますし、逆に他のソフトウェアのファイルまで誤って削除してしまえば、システムに重大な悪影響を及ぼしかねません。
 ところで、UNIX の世界では伝統的にソフトウェアはソースで配布されてきました。ソースを自分の環境に合わせて調整してコンパイルすれば、UNIX 系 OS で共通のソフトウェアが使えるというのが大きな利点なのですが、誰もが経験と勘を要するコンパイルという作業をこなせるわけではありませんし、できる人でもコンパイルが面倒になることが少なくありません。
 Linux ディストリビューションのパッケージシステムは、主にこのような煩雑さを解消するために生まれました。このシステムの元では、ソフトウェアのソースはコンパイル済みの構成ファイルを 1 つのアーカイブファイルに固めた「パッケージ」の形で配布されます。このパッケージを、パッケージマネージャにかけてインストール・削除などの指示を与えれば、ファイルの配置・回収などの作業は全てマネージャが行ってくれます。
 つまり、パッケージシステムとは、ソフトウェアをファイル単位ではなく「ソフトウェア 1 本」を単位として扱えるようにし、ソフトウェアを使えるようにするまでの手間を最低限に抑えるための機構と言えるでしょう。
 
 
3.2.3 Debian パッケージシステムとは?
 
 Linux ディストリビューションの多くは Debian プロジェクトが開発した「deb 形式」か RedHat 社が開発した「RPM 形式」のどちらかのパッケージシステムを採用しています。ARMA は deb 形式を採用しています。
 この Debian パッケージシステムは以下のような機能をもっています。
 
パッケージの依存関係の解決
 
 大半のソフトウェアは単体では動かず、他のソフトウェアや共有ライブラリがあってはじめて動くようになっています。このほか、必須ではなくてもセットで使うともっと能力を発揮できるソフトウェアの組み合わせや、逆に互いに共存できない組み合わせもあります。これらのソフトウェア同士の相性=「依存」関係は、以下のように分類されてパッケージに記録され、パッケージマネージャはこれを元に依存問題を解決しています。
 
依存
A depends B
A の動作には B が必要である。
推奨
A recommends B
A の動作には B がないと不便である。
提案
A suggests B
A の動作には B があればより便利である。
衝突
A conflicts B
A と B は共存できない。
置換
A replaces B
A は B に代わって動くことができる。
提供
A provides B
A は B の機能も提供する。
 
 
 
ネットワークから最新版をダウンロード
 
 パッケージの入手元として DVD-ROM, ハードディスクなどのローカルディスクだけでなく、HTTP, FTP, NFS などのサイトも選択できます。これにより、簡単にパッケージの配布元 (オモイカネ, Debian Project 等) から最新版をダウンロードしてアップグレードができます。
 
 
設定ファイルの保護
 
 ○
 
ソースコード形態で配布されているソフトウェアをパッケージ単位に編集する作業をする人を「メインテナ」と呼びます。ここでは詳しく述べませんが、パッケージの作成規則、リリースに関する規則、メインテナになるための規則などが、Debian プロジェクトによっていろいろと決められています。
 パッケージをアップグレードするときに、ユーザが書き換えた設定ファイルは保護され、無断では書き換えられません。また、パッケージを削除するときに設定ファイルのみを残しておくこともできます。
 
 
 
3.2.4 deb ファイルの命名規則
 
 deb パッケージはその名の通り拡張子が deb のファイルで、以下の規則によってファイル名が付けられています。
 
 
<パッケージ名>_<バージョン>_<機種>.deb
<パッケージ名>_<バージョン>-<リビジョン>_<機種>.deb
 
 
 ○
 
大半の設定ファイルは /etc 以下に保存されています。
 パッケージ名は bash, gcc などのソフトウェアの名前です。バージョンはソフトウェア作者 (以下「原作者」) が付けるソフトウェアの「版」を表す番号です。これに対して、リビジョンはソフトウェアを deb パッケージ化する際に付ける、「deb パッケージとしての版数」で、同じバージョンのソフトウェアでもパッケージ化の工程に修正を入れるたびに数字を上げていきます。機種(アーキテクチャ)はパッケージの対応機種を表し、例えば x86用は i386・機種依存しないものは all です。以上のような規則により hoge_1.2-3_i386.deb なら、ファイル名から hoge のバージョン 1.2 ・リビジョン 3 の PC 互換機用パッケージであると分かります。
バージョン番号をどう付けるは原作者の意向次第ですが、UNIX 系では慣習的に "." で区切った 0 以上の整数を使う例が多いようです。例えば、バージョン 1.0 (いち・てん・れい) を最初の正式版として、以下 1.1 , 1.2 …となります。1.9 の次も 1.10 (いち・てん・じゅう) となり、1.11 , 1.12 …と続けます。そして、全面改良や設計変更などのメジャーバージョンアップがあると、晴れて 2.0 となります。このほかに、一通りの完成 (1.0) に到達していないことを示すために 0.x というバージョンを使ったり、"." を 2 つ以上使って、1.2.34 のようにする流儀などもよく見かけられます。
リビジョン番号はメインテナが付ける番号で、通常は 1 から始まる整数や 20011028 などの日付を入れます。一般的には、1.1-1, 1.1-2 …, 1.1-10 … と続き、原作者がバージョンアップすると 1.2-1 とリビジョンを 1 に戻すようになっています。また、メインテナ以外の人が作ったパッケージを Debian で公開される NMU (Non Maintainer Update) の場合は、リビジョンに ``.'' を付けます。例えば、1.1-1 に NMU があると 1.1-1.1, 1.1-1.2 …となり、メインテナが復帰すると 1.1-2 になります。
 
 
3.2.5 パッケージマネージャ
 
 ○
 
ソフトウェアの deb パッケージ化の責任者をメインテナ (Maintainer) と言います。
 Debian には2種類のパッケージマネージャがあります。一つは低水準パッケージマネージャ dpkg 、もう一つは高水準パッケージマネージャ apt です。dpkg はそれ自体コマンド名でもありますが apt の方は apt-getapt-cache といった複数のコマンドから構成されています。〜.deb というファイル名を直接指定してパッケージをインストールする処理などは dpkg が、ダウンロードサイトの情報を調べたり、依存関係の解析をしたりする処理は apt が担当しています。
 ○
 
dpkg は Debian PacKaGe から、apt は A Package Tool からきています。
 個々の操作については、たいてい dpkg と apt で同じことができますが、インストール元や依存関係を考慮してくれる分、普通は apt の方が便利でしょう。ここでは apt を中心に、必要に応じて dpkg も使うという立場で deb パッケージの管理について解説していくことにします。
 
 
3.2.6 apt を使うための準備
 
 apt の設定ファイルは /etc/apt にまとめられています。通常このファイルは管理ツール(ogl-admin)のパッケージソース設定によって管理されてお下記のような形式になっています。
deb https://WS30XXXXXXX:ZZZZZZZ@www.omoikane.co.jp/arma_3.0_updates/deb/ogl ./
deb-src https://WS30XXXXXXX:ZZZZZZZ@www.omoikane.co.jp/arma_3.0_updates/deb/ogl ./
 (実際には折り返しはなく一行です)
 ARMA 以外に、例えば Debian サイトからアプリケーションを追加したい場合などは下記のような行を追加します。
deb http://ftp.debian.org/debian/ unstable main contrib non-free
 (実際には折り返しはなく一行です)
 上記の例では、パッケージを Debian サイトからダウンロードするよう指定しているのですが、ここで各行が下の A), B) いずれかの書式になっていることに注目してください。
 
A)
deb <ルート> <ディストリビューション> <コンポーネント(複数可)>
B)
deb <ルート> <ディレクトリ>
 
 ○
 
実際のところ apt は内部で dpkg を呼び出しています。このため「apt は dpkg のフロントエンドである」というふうにも呼ばれます。
 各行頭の deb はパッケージの入手元を指定していることを示す識別子です。apt は deb から始まる行を見付けると、あるディレクトリ (具体的な位置は後述します) から Packages.gz というファイルをダウンロードします。 これは収録パッケージの目録のようなもので、apt のパッケージデータベースの元になります。
 ここから後は、A), B) で書き方が違います。A) は多数の deb パッケージを整理して配置するのに適した構造で、Debian などの大規模なサイトが多数の deb パッケージを配布する場合に使うことが多いようです。これに対して B) は比較的単純な構造で、ソフトウェアの開発者やユーザが自作の deb パッケージをいくつか配布するのに適しています。
 まずは、A) について説明します。
 <ルート> には、Debian や ARMA があるサーバの「ルート」となる URL を指定します。例えば ftp.debian.org には /debian 以下に Debian が置かれているので、http://ftp.debian.org/debian/ となります。ローカルマシンのディスクからパッケージを入手する場合は file: に続けて、例えば file:/cdrom/debian/ のように指定します。
 ○
 
Packages.gz 以外に Release というファイルもダウンロードしますが、ここでは特に触れません。
 <ディストリビューション> には、Debian のバージョン、具体的に言えば stable, unstable, testing, frozen のいずれかを指定します。woody, sarge などのコードネームを指定することもできますが、これは Debian の開発が進むに従って[開発版→安定版→廃止]とその性格が変わってしまうのでお勧めできません。
 ○
 
正確に言うと、ディストリビューションには、<ルート>/dists にあるディレクトリを指定できます。
 <コンポーネント> には、通常 main, contrib, non-free の 3 つを指定します。以上のような A) 方式では、さらに apt が自動的にマシンの機種を判断して Packages.gz を読み込むディレクトリを決定します。例えば、先の追加の sources.list 例では以下の URL になります。
http://ftp.debian.org/debian/dists/unstable/main/binary-i386/
http://ftp.debian.org/debian/dists/unstable/contrib/binary-i386/
http://ftp.debian.org/debian/dists/unstable/non-free/binary-i386/
 B) 方式は、Packages.gz を読み込むディレクトリを <ルート> に続けて直接指定し、/ を付けてディレクトリであることを明示しておくだけです。apt はこの / の有無で A) と B) を判別するので、/ の有無は明確にする必要があります。
 なお、この Debian サイトの追加の例で挙げたサーバは全て 1 次配布元ですので、サーバに負荷を集中させないためにも、実際の sources.list には、別のサーバ (ミラーサーバ) を指定するようにしてください。国内の Debian のミラーサーバの情報も Debian プロジェクトの WWW サイトで公開されていますので参考にしてください。
 
ご注意
 
 ARMA Net プライベートリポジトリ以外からのソフトウェアを導入される場合、外部導入部分については基本的にサポートの対象外となりますので、自己責任で行っていただきますようお願い致します。
 また Debian のパッケージをインストールされる場合は直接バイナリを入れるよりも、以下のように一旦ビルドをした方がシステムの整合性が保たれやすくなります。
 
 
# apt-get source -b <ソースパッケージ名>
# dpkg -i 〜.deb
 
 
 
 
 
3.2.7 apt と dpkg の使い方
 
 apt とはいくつかのコマンド群の総称ですが、このうちよく使うコマンドは apt-get, apt-cache の 2 つです。apt-get はパッケージのインストールや削除、パッケージデータベースの更新など、実際にファイルの書き換えを伴う作業を担当します。これに対し、apt-cache はパッケージデータベースを利用した情報をユーザに提供するコマンドで、ファイルは一切書き換えません。dpkg もいくつかのコマンド群の総称ですが、パッケージマネージャとして主に使うコマンドは dpkg だけです。
 apt は自力で依存関係の問題を解決できますが、そのために現在インストールされているパッケージの削除や置換を提案することがあります。通常は提案に対して[y]と答えて構いませんが、念のため apt の提案内容を把握しておき、自分に必要なソフトウェアが使えなくなってしまう場合は[n]と答えてください。逆に、dpkg は依存関係の問題を自力で解決することはできず、エラーメッセージを出力するだけです。dpkg を使う場合は、このエラーメッセージを参考に手動で問題を解決しなければなりません。
 それでは、具体的な apt と dpkg の使い方について説明していきましょう。
 
パッケージデータベースの更新 (apt-get update)
 
 Packages.gz などのパッケージデータベースをダウンロードし、/var/lib/apt/lists に保存します。Packages.gz は収録パッケージが更新される度に変わります。DVD-ROM からパッケージを入手する場合は、同じ DVD-ROM を使う限りデータベースも変化しないので update の必要はありません。通常はパッケージソースを ARMA Net にしておきオモイカネ社のアラート情報が発行されたタイミングで実行します。
 
 
# apt-get update
 
 
 
 
パッケージのインストール (apt-get install / dpkg -i)
 
 パッケージをインストールします。apt-get installdpkg -i は似た機能ですが、apt-get は「パッケージ名」を指定すれば apt が最新版を探して自動的にダウンロードしインストールまでするのに対し、dpkg では直接インストールする「deb ファイル名」を指定しなければなりません。dpkg の方が気が利かないようですが、敢えて最新版でないパッケージをインストールしたい場合などには、dpkg -i でしか対応できないなど重宝することもあります。なお、apt-get は最新版が既にインストールされていると処理を行いませんが、--reinstall をつけると強制的に再インストールできます。
 
 
# apt-get [--reinstall] install <パッケージ(複数可)>
# dpkg -i <*.deb(複数可)>
 
 
 
 
パッケージの削除 (apt-get [--purge] remove / dpkg -r / dpkg -P)
 
 インストールされているパッケージを削除します。--purge をつけると、remove だけでは削除されない設定ファイル類も含めて「パージ」(完全削除) します。ただし「削除」した段階で、apt のデータベースからもパッケージの情報が削除されるため、既に「削除」されているパッケージをさらに「パージ」する場合は dpkg -P しか使えません。
 
 
# apt-get [--purge] remove <パッケージ(複数可)>
# dpkg {-r|-P} <パッケージ(複数可)>
 
 
 
 
パッケージのアップグレード (apt-get upgrade / apt-get dist-upgrade)
 
 インストールされているパッケージを最新版へアップグレードします。
 
 
# apt-get upgrade
# apt-get dist-upgrade
 
 
 なお、アップグレードのために自分以外のパッケージの追加や置換が必要になる場合は、安全のため upgrade でのアップグレード対象から外されます。dist-upgrade ではこのような場合も構わずアップグレードをします。dist-upgrade でなく部分的に最新版にアップグレードする場合は apt-get install <パッケージ> として、明示的にパッケージを指定します。
 
 
# apt-get upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages have been kept back
  hoge
0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
# apt-get install hoge
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
  libhoge1 
The following NEW packages will be installed:
  libhoge1 
1 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 1234kB of archives. After unpacking 5.6MB will be used.
Do you want to continue? [Y/n] 
 
 
 
 
パッケージの一覧 (dpkg -l)
 
 ○
 
正確に言うと、コンポーネントには、<ルート>/dists/<ディストリビューション> にあるディレクトリを指定できます。
 条件に当てはまるパッケージの一覧を表示します。条件を指定しないとインストールされているパッケージの一覧が表示されます。
 
 
$ dpkg -l [<条件>]
 
 
 
 
パッケージの検索 (apt-cache search)
 
 パッケージデータベースからキーワードを含むパッケージを探して表示します。通常はパッケージの紹介文なども検索の対象になりますが、--names-only を付けると「パッケージ名にキーワードを含む」もののみが検索の対象になります。
 
 
$ apt-cache [--names-only] search <キーワード>
 
 
 
 
パッケージの情報を表示 (apt-cache show / dpkg -I)
 
 ○
 
条件にはワイルドカードも使えますが、このときシェルにワイルドカードを展開されてしまわないよう「'」(シングルクウォート)や「"」(ダブルクウォート)で条件を囲んでおきましょう。
 パッケージの依存情報・バージョン・サイズ・管理者・簡単な紹介などの付属情報を表示します。apt-cache ではパッケージデータベースから検索しますが、dpkg -I では deb ファイルから情報を直接読み込みます。そのため、apt-cache show ではパッケージ名、dpkg -I では deb ファイルを指定するという違いがあります。
 apt-cache show では、複数のバージョンのパッケージが見つかるとそれぞれの情報を表示します。例えばネットワーク上にある最新版とインストールされているパッケージのバージョンが違う場合などがこれに当てはまります。
 
 
$ apt-cache show <パッケージ(複数可)>
$ dpkg -I <*.deb (複数可)>
 
 
 
 
パッケージとファイルの相互検索 (dpkg -L / dpkg -S / dpkg -c)
 
 パッケージに含まれるファイル名を調べたり、逆にファイル名を指定してそのファイルがどのパッケージに含まれていたかを検索したりすることができます。パッケージ名を指定して中に含まれるファイルを一覧表示するには dpkg -L を、逆にファイル名を指定してどのパッケージからインストールされたものかを調べるには dpkg -S を使います。また、特定の deb ファイルの中身を見るには dpkg -c を使います。
 
 
$ dpkg -L <パッケージ(複数可)>
$ dpkg -S <ファイル(複数可)>
$ dpkg -c <*.deb (複数可)>
 
 
 
 
キャッシュファイルの整理 (apt-get autoclean / apt-get clean)
 
 apt-get はダウンロードしたパッケージを /var/cache/apt/archives に保存しています。このキャッシュにより同じファイルを何度もダウンロードしなくて済むのですが、キャッシュは自動的には削除されないため、このディレクトリには徐々に古いパッケージが溜まってきてしまいます。そこで、autoclean で最新版だけを残して古いキャッシュを削除したり、clean で全キャッシュを削除したりしして整理をします。
 
 
# apt-get autoclean
# apt-get clean
 
 
 
 
パッケージのホールド
 
 ○
 
apt-get install / dpkg -i の場合と同じ状況です。
 ソフトウェアの仕様が変わった直後など、あえてパッケージをアップグレードしたくないときは、パッケージをホールド (Hold) して apt-get upgrade の対象から外すことができます。ここでは「カーネル 2.6.31.6 はもう固定しておきたいな」というケースを想定して説明します。
 この場合ホールドを設定するには、dpkg の機能を使って、root で以下のようにコマンドを実行します。
 
 
# echo 'kernel-2.6.31.6 hold' | dpkg --set-selections
 
 
 ○
 
ここではコマンドラインベースでの作業を紹介しますが、この他に dselect というインターフェースを使用して設定することもできます。
 正しくホールドされたかどうかは dpkg -l で確かめることができます。行頭が h になっていればホールドがうまくいっています。
 
 
# dpkg -l kernel-2.6.31.6
要望=(U)不明/(I)インストール/(R)削除/(P)完全削除/(H)維持
| 状態=(N)無/(I)インストール済/(C)設定/(U)展開/(F)設定失敗/(H)
|/ エラー=(空欄)無/(H)維持/(R)要再インストール/X=両方
||/ 名前                バージョン         説明
+++-=================-================-===============================
hi  kernel-2.6.31.6     1               Linux kernel for ARMA/OGL
 
 
 この状態では kernel-2.6.31.6 は自動的に更新されることはなくなります。ホールド解除は、echo コマンドの引数の hold の部分を install とします。
 
 
# echo 'kernel-2.6.31.6 install' | dpkg --set-selections
 
 
 この他に apt-get install などで明示的にパッケージを再インストールしてもホールドは解除されます。
 
 
正常にインストールできていないパッケージを探す
 
 dpkg -l では正常にインストールされているパッケージは、先頭 2 文字を ii または hi (ホールドの場合) で表します。よって、以下のようなコマンドラインで異常な状態のパッケージの一覧を得ることができます。
 
 
$ dpkg -l | grep -v "^[hi]i" 
要望=(U)不明/(I)インストール/(R)削除/(P)完全削除/(H)維持
| 状態=(N)無/(I)インストール済/(C)設定/(U)展開/(F)設定失敗/(H)
|/ エラー=(空欄)無/(H)維持/(R)要再インストール/X=両方
||/ 名前         バージョン     説明
+++-============-==============-======================================
iU  hoge1        1.2-3          Hoge No.1
rc  hoge2        2.3-4          Hoge No.2
iFX hoge3        3.4-5          Hoge No.3
 
 
 hoge1 はパッケージが展開されただけで、設定が終わっていないパッケージです。依存関係の解決を含め、パッケージを再インストールするのが有効でしょう。
 hoge2 は削除されたが完全削除 (パージ) はされていず、設定ファイルが残っているパッケージです。設定ファイルを残したければそのままで構いませんが、dpkg -P でパージすることもできます。
 hoge3 のように先頭から 3 文字目があるパッケージはエラーを起こしています。エラーへの対処は一口では説明できませんが、パッケージを一旦削除してから再インストールするのが多くの場合有効です。
 
 
不要なパッケージの一覧
 
 deborphan は使われていない共有ライブラリなど、不要なパッケージを検索してくれるコマンドです。--guess-all などのオプションを付けると、検索対象とするパッケージの範囲を広げられます。詳しくは man deborphan を参照してください。
 
 
$ deborphan [<オプション>]
 
 
 
 
プロキシサーバの利用
 
 環境変数 ftp_proxy, http_proxy にプロキシサーバのプロトコル・ホスト名・ポート番号を http://cosmos:8080/ のように設定しておくと、apt-get はプロキシ経由でファイルをダウンロードします。
 
 
可能な範囲で apt-get の作業を続ける
 
 ミラーサイトからパッケージをダウンロードする場合、ミラーリングのタイミングによっては Packages.gz と実際にサーバ上に存在するパッケージが一致しないために、パッケージをダウンロードできないことがあります。通常は 1 つでもダウンロードできないパッケージがあるとインストールやアップグレードは行いませんが、apt-get -m とすると、ダウンロードできたパッケージで可能な作業を続けさせることができます。
 
 
# apt-get -m [<パラメータ>]
 
 
 
 
apt-get のエミュレーション
 
 apt-get, dpkg では、実際にパッケージをインストールしたり削除したりせず、作業をする「ふり」をして、どのような作業を行うかを表示するだけのオプションがあります。多くのパッケージを一気に操作する前には、この機能を使って事前に何が行われるのかを調べておくと安心です。
 
 
# apt-get -s [<各パラメータ>]
# dpkg --no-act [<各パラメータ>]
 
 
 
 
 
3.2.8 パッケージのディレクトリ構成
 
 
パッケージプール
 
 ○
 
dpkg --get-selections でも確かめることができます。
 ARMA や Debian ではパッケージはパッケージプール(package pool)と呼ばれるディレクトリ形式に従って配置され、バージョンや対応機種に関係なく同じソフトウェアのパッケージを 1 つのディレクトリにまとめて管理しています。例として、架空のパッケージ hoge のパッケージが 1 つのディレクトリに収められている様子を表します。
 
 
$ ls pool/main/h/hoge
libhoge1_1.2-3_i386.deb    hoge_1.2-3_i386.deb
libhoge1_1.2-3_arm.deb     hoge_1.2-3_arm.deb
libhoge0_0.9-8_i386.deb    hoge_0.9-8.diff.gz
libhoge0_0.9-8_arm.deb     hoge_0.9-8.dsc
libhoge-dev_1.2-3_all.deb  hoge_0.9-8_i386.deb
libhoge-dev_0.9-8_all.deb  hoge_0.9-8_arm.deb 
hoge_1.2-3.diff.gz         hoge_1.2.3.orig.tar.gz
hoge_1.2-3.dsc             hoge_0.9.8.orig.tar.gz
 
 
 ここでは x86用と ARM 用のパッケージのみを挙げていますが、本来は他アーキテクチャ用のパッケージも全て同じディレクトリに入っています。また、hoge のソースから作られたパッケージならバージョンも関係なく stable 用の 0.9-8、testing/unstable 用の 1.2-3 の両方が入っていますし、バイナリだけでなくソースパッケージも同じディレクトリに配置されます。パッケージ hoge に関係する配布物はすべて同じディレクトリに置かれているということになります。
 
 
サイトレベルのディレクトリ
 
 プールの上位にはサイトレベルのディレクトリがあります。この構造は通常パッケージシステム(apt)に隠蔽されていますが、参考情報として説明します。
 ○
 
2000年12月からこのような形態になっています。
 ARMA の CD/DVD-ROM や ARMA Net リポジトリでは以下のようなディレクトリツリーで配布されています。
 
 
/ -+- arma_3.0_updates
   +- arma_3.0_updates --- deb -+- Packages.gz
                                +- hogehoge_2.3-4o5_i386.deb
                                +- hogehoge_2.3-4.orig.tar.gz
                                +- hogehoge_2.3-4o5.dsc
                                +- hogehoge_2.3-4o5.diff.gz
                                |
 
 
 また Debian のサイトでは以下のような構造化されたディレクトリツリーを持っています。下記で / は配布物の「ルート」を表します。例えば、Debian の公式サイトでは http://ftp.debian.or.jp/debian/ が以下の / に相当します。
 
 
/-+- dists -+- sid -+- main -----+- binary-all
  |         |       +- contrib   +- binary-armel
  |         |       `- non-free  +- binary-i386 ---- Packages.gz
  |         +- squeeze
  |         +- stable -> lenny
  |         +- testing -> squeeze
  |         `- unstable -> sid
  |
  `-pool--+--main -----+- a
          +--contrib   +- b
          `--non-free  +- c
                       |
                       +- h -+- hoge --+- libhoge1_1.2-3_i386.deb
                       |     |         +- libhoge1_1.2-3_arm.deb
                       |               +- libhoge0_0.9-8_i386.deb
                       |               |
                       |               `- hoge_0.9.8.orig.tar.gz  
                       `- z
 
 ○
 
OGL1.2 までは ogl ディレクトリと並んで、debian, debian-jp, debian-non-US ディレクトリがありました。ARMA2以降で ogl ディレクトリに一本化されました。

COPYRIGHT (C)2013, オモイカネ株式会社 (Omoikane Inc.)
E-mail: info@omoikane.co.jp