第2章 Debianパッケージ管理

目次

2.1. Debainパッケージ管理の前提条件
2.1.1. パッケージ設定
2.1.2. 基本的な注意事項
2.1.3. 永遠のアップグレード人生
2.1.4. Debianアーカイブの基本
2.1.5. パッケージ依存関係
2.1.6. パッケージ管理のイベントの流れ
2.1.7. パッケージ管理のトラブルへの応急対処法
2.2. 基本的パッケージ管理操作
2.2.1. コマンドラインによる基本的なパッケージ管理操作
2.2.2. aptitudeのインタラクティブな使用
2.2.3. aptitudeのキーバインディング
2.2.4. aptitudeの下でのパッケージの表示
2.2.5. aptitudeを使った探索方法
2.2.6. aptitudeのregex式
2.2.7. aptitudeによる依存関係の解決
2.2.8. パッケージアクティビティーログ
2.2.9. Aptitudeの長所
2.3. aptitude操作例
2.3.1. regexにマッチするパッケージ名のパッケージをリスト
2.3.2. regexマッチをして閲覧
2.3.3. パッケージを本当に完全削除
2.3.4. 自動/手動インストールの状態の整理
2.3.5. aptitudeを使ったシステム全体のアップグレード
2.4. 高度なパッケージ管理操作
2.4.1. コマンドラインによる高度なパッケージ管理操作
2.4.2. インストールされたパッケージファイルの検証
2.4.3. パッケージの問題に対する防御
2.4.4. パッケージメタデータの検索
2.5. Debianパッケージ管理の内部
2.5.1. アーカイブのメタデータ
2.5.2. トップレベルの"Release"ファイルと信憑性
2.5.3. アーカイブレベルの"Release"ファイル
2.5.4. パッケージメタデータの取得
2.5.5. APTに関するパッケージ状態
2.5.6. aptitudeに関するパッケージ状態
2.5.7. 取得したパッケージのローカルコピー
2.5.8. Debianパッケージファイル名
2.5.9. dpkgコマンド
2.5.10. update-alternativeコマンド
2.5.11. dpkg-statoverrideコマンド
2.5.12. dpkg-divertコマンド
2.6. 壊れたシステムからの回復
2.6.1. 古いユーザの設定との非互換性
2.6.2. 重複するファイルを持つ相異なるパッケージ
2.6.3. 壊れたパッケージスクリプトの修正
2.6.4. dpkgコマンドを使っての救済
2.6.5. パッケージセレクションの回復
2.7. パッケージ管理のヒント
2.7.1. Debianパッケージの選択方法
2.7.2. 混合したアーカイブソースからのパッケージ
2.7.3. 候補バージョンの調整
2.7.4. VolatileとBackports.org
2.7.5. パッケージの自動ダウンロードとアップグレード
2.7.6. APTのよるダウンロードバンド幅の制限
2.7.7. 緊急ダウングレード
2.7.8. 誰がパッケージをアップロードしたのか?
2.7.9. equivsパッケージ
2.7.10. 安定版システムへのパッケージ移植
2.7.11. APTのためのプロキシサーバー
2.7.12. 小さな公開パッケージアーカイブ
2.7.13. システム設定の記録/コピー
2.7.14. 外来のバイナリパッケージを変換やインストールする
2.7.15. dpkgを使わずにパッケージを開梱
2.7.16. パッケージ管理の追加参考文書
[注意] 注意

本章は最新安定版リリースがコード名:lennyと言う前提で書かれています。

Debianは、フリーソフトウエアのコンパイル済みバイナリパッケージからなる整合性あるディストリビューションを作り、そのアーカイブを通じてそれらを頒布するボランティア組織です。

Debianのアーカイブは、HTTPやFTP法によるアクセスされるための多くのリモートのミラーサイトとして提供されています。それは、CD-ROM/DVDによっても提供されています。

Debianのパッケージ管理システムは、適切に使われればバイナリパッケージの整合性ある組み合わせがアーカイブからシステムにインストールされるようになっています。現在、amd64アーキテクチャーには25441つのパッケージがあります。

Debianのパッケージ管理システムは、多彩な歴史があり、使用されるフロントエンドのユーザプログラムやバックエンドのアーカイブへのアクセス方法に多くの選択肢があります。現在はDebianのパッケージ管理活動のメインフロントエンドプログラムとしてaptitude(8)を推薦します。

表2.1 Debianのパッケージ管理ツールのリスト。

パッケージ popcon サイズ 説明
aptitude V:26, I:97 9832 ターミナルベースのパッケージマネージャ(現在の標準、aptのフロントエンド)
apt V:90, I:99 5128 アドバンスドパッケージツール(APT)、"http"や"ftp"や"file"というアーカイブへのアクセス方法をdpkgに提供するフロントエンド(apt-get/apt-cacheコマンドを含む)
tasksel V:7, I:93 900 Debianシステムにタスクをインストールするための選択ツール(APTのフロントエンド)
unattended-upgrades V:4, I:26 212 APTの拡張パッケージでセキュリティアップデートの自動インストールを可能にする
dselect V:4, I:57 2060 ターミナルベースのパッケージマネージャ(過去の標準、APTや他の古いアクセス法のフロントエンド)
dpkg V:91, I:99 6864 Debianのためのパッケージ管理システム
dpkg-ftp V:0.08, I:0.5 136 dselectのための古いftp
synaptic V:20, I:48 6104 グラフィカルなパッケージマネージャ(APTのGNOMEフロントエンド)
gnome-apt V:0.3, I:1.9 NOT_FOUND グラフィカルなパッケージマネージャ(APTのGNOMEフロントエンド)
kpackage V:5, I:14 1064 グラフィカルなパッケージマネージャ(APTのKDEフロントエンド)
apt-utils V:52, I:99 460 APTユーティリティプログラム: apt-extracttemplates(1)とapt-ftparchive(1)とapt-sortpkgs(1)
apt-listchanges V:3, I:6 264 パッケージ変更履歴の通知ツール
apt-listbugs V:1.4, I:2 436 APTによる各インストール前にクリチカルバグをリストする
apt-file V:2, I:9 172 APTパッケージ探索ユーティリティ -- コマンドラインインターフェース
apt-rdepends V:0.16, I:0.9 92 パッケージの依存関係を再帰的にリスト

[注意] 注意

aptitudeapt-getコマンドの両方を混用する際に迷惑だったバグ #411123は解決されました。もし本件のためにaptitude(8)を使うことに躊躇しているなら、御再考下さい。

2.1. Debainパッケージ管理の前提条件

2.1.1. パッケージ設定

Debianシステム上でのパッケージ設定の要点は次です:

  • システム管理者による手動の設定は尊重されます。言い換えれば、パッケージ設定システムは利便性のために勝手な設定をしません。
  • 各パッケージは、パッケージ導入プロセスを助けるためのdebconf(7)と呼ばれる標準化されたユーザインターフェースを使用し、それぞれ毎の設定スクリプトとともに提供されます。
  • Debianの開発者はパッケージの設定スクリプトによりユーザのアップグレードが滞りなく進むように最大限の努力を行います。
  • システム管理者にはパッケージされたソフトウエアの全機能が使用可能です。ただしセキュリティリスクのある機能はデフォルトのインストール状態では無効にされています。
  • セキュリティリスクのあるサービスを手動でアクティベートした場合は、リスクの封じ込めはあなたの責任です。
  • システム管理者は難解奇異な設定を手動で有効にできます。ただこんなことをすればポピュラーな一般の補助プログラムとは干渉してしまうかもしれません。

2.1.2. 基本的な注意事項

[警告] 警告

ランダムな混合のスイーツからパッケージを導入してはいけません。コンパイラーのABIとかライブラリー のバージョンとかインタープリターの機能等のシステム管理に関する深い知見が必要なパッケージの整合性がきっと破壊されます。

初心者のDebianシステム管理者はDebianの安定版stableリリースをセキュリティアップデートを適用しながら使うべきです。Debianシステムを非常によく理解するまでは、用心として次の有効なアクションですら避けておくべきと考えます:

  • "/etc/apt/sources.list"の中にテスト版testingとか不安定版unstableとかを含めないようにします。
  • "/etc/apt/sources.list"の中に標準のDebianとDebian以外のUbuntuのようなアーカイブを混在させない、
  • "/etc/apt/preferences"を作成しない。
  • パッケージ管理ツールのデフォルトを影響を理解せずに変更しない。
  • ランダムなパッケージを"dpkg -i <random_package>"でインストールしない。
  • ランダムなパッケージを"dpkg --force-all -i <random_package>"で絶対インストールしない。
  • "/var/lib/dpkg/"の中のファイルを消去や改変しない。
  • ソースから直接コンパイルしたソフトウエアプログラムをインストールする際にシステムファイルを上書きしない。(こういったソフトウエアプログラムは"/usr/local"か"/opt"の中にインストールしましょう。)

上記のアクションで起きるDebianパッケージシステムへのコンパチブルでない効果はシステムを使えなくするかもしれません。

ミッションクリティカルなサーバーを走らせる真剣なDebianシステム管理者は更なる用心をすべきです:

  • 安全な条件下であなたの特定の設定で徹底的にテストすることなくセキュリティアップデートをも含めた如何なるパッケージもインストールをしてはいけません。(Debianは非常に安定なシステムを長期間提供し続けてきているとは言え、最終的にはあなたのシステムへの責任はシステム管理者であるあなた自身が負っています。)

2.1.3. 永遠のアップグレード人生

私が上記で警告したとはいえ、自分自身で管理するデスクトップ環境ではDebianのテスト版testingや不安定版unstableのスイーツを自分のメインのシステムとして使おうと多くの本書の読者が望むことは分かっています。システムは非常に快調に動くし、頻繁に更新されるし、最新の機能が提供されるからです。

[注意] 注意

あなたの業務サーバーには、セキュリティアップデートをした安定版stableスイーツを推薦します。例えばあなたの母親のPCのように、管理に限られた時間しか割けないデスクトップPCに関しても同様の事が言えます。

"/etc/apt/sources.list"の中のディストリビューション文字列を、"testing"とか"unstable"というスイーツ名、もしくは"squeezeとか"sid"というコード名に単に設定するだけで十分です。

testingunstableを使うことは大変楽しいけれど、リスクがついてきます。Debianシステムのunstableスイーツさえおおむね非常に安定に見えますが、Debianシステムのtestingunstableスイーツでは過去パッケージ上の問題をいくつか経験して来てるし、その一部は簡単には解決できないものでした。結構痛い目に会うことになるかもしれませんよ。時々、壊れたパッケージや機能の欠損が数週間続くことが起こります。

Debianパッケージのバグからの早急かつ簡単な回復を確実にするいくつかのアイデアがここにあります:

  • Debianシステムの安定版stableスイーツを別のパーティションにインストールし、システムをヂュアルブータブルにします。
  • レスキューブートのためのインストール用CDを手元に置いておく。
  • apt-listbugsをインストールしてアップグレードの前にDebianバグトラッキングシステム(BTS)をチェックすることを考る。
  • 問題回避するのに十分なだけのパッケージシステムの基盤を学ぶ。
  • chrootか類似の環境を作り事前に最新のシステムを実行します。(任意)

(これらの用心のための方策の何れもできないなら、テスト版testingや不安定版unstableスイーツを使うのにはあなたはきっと準備不足です。)

以下に記すことにより悟りを開けば、アップグレード地獄という果てしない因果応報の葛藤から人は解脱し、Debianの涅槃の境地に到達できます。

2.1.4. Debianアーカイブの基本

Debianアーカイブをシステムユーザの視点から見てみましょう。

[ティップ] ティップ

Debianアーカイブの正式のポリシーはDebianポリシーマニュアル、第2章 - Debianアーカイブに規定されています。

典型的なHTTPアクセスの場合、現在の安定版stable=lennyシステムを例にとると"/etc/apt/sources.list"ファイルの中にアーカイブは次の様に規定されています。

deb http://ftp.XX.debian.org/debian/ lenny main contrib non-free
deb-src http://ftp.XX.debian.org/debian/ lenny main contrib non-free

deb http://security.debian.org/ lenny/updates main contrib
deb-src http://security.debian.org/ lenny/updates main contrib

"ftp.XX.debian.org"はあなたの所在場所に合う、Debianの全世界ミラーサイトリスト中に見つかるミラーサイトのURL、例えば日本なら "ftp.jp.debian.org"、に置き換えなければいけません。これらのサーバーの状況はDebianミラー確認サイトで確認できます。

上記で、次の安定版stableがリリースされて驚かされ無いように、私はスイート名の"stable"でなくコード名の"lenny"を使います。

"/etc/apt/sources.list"の意味はsources.list(5)に記載されていて、要点は:

  • "deb"行がバイナリパッケージのための定義です。
  • "deb-src"行がソースパッケージのための定義です。
  • 一番目の引数は、Debianアーカイブのroot URLです。
  • 二番目の引数は、スイーツ名かコード名のどちらかで与えられるディストリビューション名です。
  • 三番目次の引数は、Debianアーカイブの中の有効なアーカイブのコンポーネント名のリストです。

ソース関連のメタデータにアクセスしないaptitudeのためだけなら"deb-src"行は安全に省略(もしくは"#"を行頭に挿入してコメントアウト)することができます。こうするとアーカイブのメタデータの更新速度が向上します。URLは"http://"や"ftp://"や"file://"等々の何れも可能です。

[ティップ] ティップ

もし上記の例で"lenny"ではなく"sid"が使われる場合には、セキュリティアップデートのための"deb: http://security.debian.org/ ..."行は不要です。安定版stableとテスト版testing(即ちlennysqueeze)にのみセキュリティアップデートがあります。

次は設定ファイル内に用いられるDebianアーカイブサイトのURLとスイーツ名もしくはコード名です。

表2.2 Debianアーカイブサイトのリスト。

アーカイブのURL スイート名(コード名) 目的
http://ftp.XX.debian.org/debian/ stable (lenny) 安定版(lenny)のリリース
http://ftp.XX.debian.org/debian/ testing (squeeze) テスト版(squeeze)のリリース
http://ftp.XX.debian.org/debian/ unstable (sid) 不安定版(sid)のリリース
http://ftp.XX.debian.org/debian/ experimental 実験的プリリリース(任意、開発者専用)
http://ftp.XX.debian.org/debian/ stable-proposed-updates 次回安定版ポイントリリース用のアップデート(任意)
http://security.debian.org/ stable/updates 安定版用のセキュリティアップデート(重要)
http://security.debian.org/ testing/updates テスト版用のセキュリティアップデート(重要)
http://volatile.debian.org/debian-volatile/ volatile スパムフィルタやIMクライアント他用のコンパチブルなアップデート
http://volatile.debian.org/debian-volatile/ volatile-sloppy スパムフィルタやIMクライアント他用のノンコンパチブルなアップデート
http://backports.org/debian/ lenny-backports lennyのためのバックポートされたパッケージ。(非正規、任意)

[注意] 注意

セキュリティアップデートされた純粋な安定版stableリリースのみが最善の安定性を提供します。一部testingunstable由来のパッケージを混用してほとんどstableリリースを走らせることは、純粋なunstableリリースを走らせるよりリスクがあります。stableリリースの下で最新バージョンのいくつかのプログラムが本当に必要なら、debian-volatileプロジェクトbackports.org(「VolatileとBackports.org」参照)サービスからのパッケージを使って下さい。これらのサービスは細心の注意を持って使う必要があります。

[注意] 注意

基本的に、stabletestingunstableのスイーツの内の1つだけを"deb"行に書くべきです。もし、stabletestingunstableのスイーツの何らかの組み合わせを"deb"行に書けば、APTプログラムは、最新のアーカイブのみが有効であるにもかかわらず、実行速度が低下します。"/etc/apt/preferences"ファイルがはっきりとした目的を持って使われている場合(「候補バージョンの調整」)のみ複数のリストに意味があります。

[注意] 注意

stabletestingスイーツのDebianシステムでは、上記の例のようにセキュリティアップデートを有効とするように"/etc/apt/sources.list"の中に"http://security.debian.org/"の行を含めることはいいことです。

各Debianアーカイブは3つのコンポーネントから成り立っています。コンポーネントには"Debianポリシー"ではカテゴリとか"Debian社会契約"ではエリアという別名が使われています。コンポーネントは"Debianフリーソフトウエアガイドライン" (DFSG)に準拠しているかどうかによって分類されています。

表2.3 Debianアーカイブコンポーネントのリスト。

コンポーネント パッケージ数 クライテリア
main 24828 パッケージはDSFGに完全準拠し、non-freeのパッケージに依存していない。(main=主要)
contrib 207 パッケージはDSFGに完全準拠するが、non-freeのパッケージに依存しています。(contrib=寄与)
non-free 406 パッケージはDSFGに完全には準拠しないが、頒布可能で有用です。(non-free=非自由)

ここで、上記にあるパッケージ数はamd64アーキテクチャーに関する数字である。厳密に言うなら、mainコンポーネントのアーカイブのみをDebianシステムと考えるべきです。

Debianアーカイブの構成は、各アーカイブのURLの後ろにdistspoolをつけたURLにブラウザを向ければ学習できます。

ディストリビューションは、スイーツとコード名の2つの方法で言及されます。この他にディストリビューションと言う言葉は多くの文書でスイーツの同義語としても使われています。スイーツとコード名の関係は次のようにまとめられます:

表2.4 スイーツとコード名の関係。

タイミング スイーツ = 安定版 stable スイーツ = テスト版 testing スイーツ = 不安定版 unstable
lennyリリース後 コード名 = lenny コード名 = squeeze コード名 = sid
squeezeリリース後 コード名 = squeeze コード名 = squeeze+1 コード名 = sid

コード名の歴史は、Debian FAQ: 6.3.1 Which other codenames have been used in the past?に記載されています。

比較的厳格なDebianアーカイブの用語法では、"セクション"という言葉はアプリケーションの分野によるパッケージ分類に特化して使われます。(しかし、"mainセクション"という言葉はmainコンポーネントを提供するDebianアーカイブ部分を表現するのにしばしば使われています。)

Debianデベロッパー(DD)が不安定版unstableアーカイブに新たなアップロードを(incomingでの処理を経由して)する度毎に、アップロードするパッケージが最新の不安定版unstableアーカイブの最新のパッケージ集合とコンパチブルであるようにする義務がDDにはあります。

重要なライブラリーのアップグレード他の理由でDDがこのコンパチビリティーを壊す際には、debian-develのメーリングリスト他に通常アナウンスがされます。

Debianのアーカイブ管理スクリプトによって非安定版unstableアーカイブからテスト版testingアーカイブへパッケージ集合が移動される前に、アーカイブ管理スクリプトはパッケージの成熟度(約10日経過)とRCバグレポート状況を確認するばかりでなく、テスト版testingアーカイブの最新パッケージ集合とのコンパチブルであるようにするように努めます。このプロセスがあるので、テスト版testingアーカイブは非常に新しくかつ使いやすいのです。

リリースチームによる徐々のアーカイブ凍結過程を通じて、少々の手動の介入を伴いつつテスト版testingアーカイブは完全に整合性をもったバグの無い状態へと徐々に熟成されます。そして、古いテスト版testingアーカイブのコード名を新たな安定版stableアーカイブへと割り当て、新たなコード名を新たなテスト版testingアーカイブへと割り当てることで、新たな安定版stableがリリースされます。新たなテスト版testingアーカイブの当初の内容は、新たにリリースされた安定版stableアーカイブとまったく同じです。

不安定版unstableもテスト版testingアーカイブもともに一時的に次のような理由で細かな問題発生があるかもしれません:

  • ブロークンなパッケージのアーカイブへのアップロード(主にunstableにて)。
  • 新たなパッケージをアーカイブに受け入れる際の遅れ(主にunstableにて)。
  • アーカイブの同期のタイミング問題(testingunstableの両方にて)。
  • パッケージの除去などのアーカイブへの手動の介入(どちらかといえばtestingにて)、等。

もしこれらのアーカイブを使おうと考えるなら、この種の細かな問題の修復や回避は必須技能です。

[注意] 注意

たとえいつも非安定版unstableやテスト版testingアーカイブを使っていようとも、ほとんどのデスクトップユーザは新たな安定版stableリリースの後約数ヶ月はセキュリティアップデートされた安定版stableアーカイブを使うべきです。この移行期は、非安定版unstableもテスト版testingアーカイブの何れももほとんどの人に良いものではありません。非安定版unstableアーカイブを使おうとすると、核となるパッケージが大アップグレードの嵐に見舞われるので、あなたのシステムをうまく使える状態に保つのは困難です。テスト版testingアーカイブを使おうとしても、安定版stableアーカイブとほとんど同じ内容でセキュリティサポートはありません(Debian testing-security-announce 2008-12)。1ヶ月ほど経てば、非安定版unstableアーカイブなら注意を払えば使えるかもしれません。

[ティップ] ティップ

テスト版testingアーカイブを追跡している際には、除去されたパッケージによって引き起こされる問題は該当するバグ修正のためにアップロードされたパッケージを非安定版unstableアーカイブからインストールすれば通常回避できます。

次の定義はDebianポリシーマニュアル参照:

2.1.5. パッケージ依存関係

Debianシステムはコントロールファイル中のバージョン情報付きのバイナリ依存関係宣言を通して整合性のあるバイナリパッケージの集合を提供します。ここにその少々簡素化しすぎの定義を示します。

表2.5 パッケージ依存関係のリスト。

パッケージ依存関係 意味
Depends これは絶対依存を宣言し、このフィールドにリストされた全てのパッケージは同時または事前にインストールされていなければいけません。
Pre-Depends これは、リストされたパッケージが事前にインストールを完了している必要がある以外は、Dependsと同様です。
Recommends これは強いが絶対でない依存を宣言します。多くのユーザはこのフィールドにリストされたパッケージ全てが導入されていなければ、当該パッケージを望まないでしょう。
Suggests これは弱い依存を宣言します。このパッケージの多くのユーザはこのフィールドにリストされたパッケージを導入すればメリットを享受できるとは言え、それら抜きでも十分な機能が得られます。
Enhances これはSuggests同様の弱い依存を宣言しますが、依存作用の方向が逆です。
Conflicts これは絶対的排他関係を宣言します。このフィールドにリストされた全てのパッケージを除去しない限り当該パッケージを導入できません。
Replaces 当該パッケージによりインストールされるファイルがこのフィールドにリストされたパッケージのファイルを置き換える際にこれを宣言します。
Provides 当該パッケージがこのフィールドにリストされたパッケージのファイルと機能の全てを提供する際にこれを宣言します。

[注意] 注意

正常な設定としてProvidesとConflictsとReplacesとを単一バーチャルパッケージに対し同時宣言することがあります。こうするといかなる時にも当該バーチャルパッケージを提供する実パッケージのうち確実に一つだけがインストールされます。

ソースの依存関係をも含む正式の定義はthe Policy Manual: Chapter 7 - Declaring relationships between packagesにあります。

2.1.6. パッケージ管理のイベントの流れ

パッケージ管理の簡略化されたイベントの流れをまとめると次のようになります。

  • 更新 ("aptitude update"か"apt-get update"):

    1. アーカイブメタデータをリモートアーカイブから取得。
    2. APTが使えるようローカルメタデータを再構築し更新。
  • アップグレード("aptitude safe-upgrade"と"aptitude full-upgrade"か、"apt-get upgrade"と"apt-get dist-upgrade"):

    1. APTシステムは最新バージョンが普通選ばれる候補バージョンを全てのインストール済みパッケージに関して決定します。(例外については「候補バージョンの調整」参照。)
    2. パッケージ依存関係の解決。
    3. もし候補バージョンがインストール済みバージョンとことなる際には、選ばれたバイナリパッケージをリモートアーカイブから取得。
    4. 取得バイナリパッケージの開梱。
    5. preinstスクリプトの実行
    6. バイナリファイルのインストール。
    7. postinstスクリプトの実行。
  • インストール ("aptitude install ..."か"apt-get install ..."):

    1. コマンドラインにリストされたパッケージの選択。
    2. パッケージ依存関係の解決。
    3. 選ばれたバイナリパッケージをリモートアーカイブから取得。
    4. 取得バイナリパッケージの開梱。
    5. preinstスクリプトの実行
    6. バイナリファイルのインストール。
    7. postinstスクリプトの実行。
  • 削除 ("aptitude remove ..."か"apt-get remove ..."):

    1. コマンドラインにリストされたパッケージの選択。
    2. パッケージ依存関係の解決。
    3. prermスクリプトの実行
    4. 設定ファイル以外のインストール済みファイルの削除。
    5. postrmスクリプトの実行。
  • 完全削除 ("aptitude purge ..."か"apt-get purge ..."):

    1. コマンドラインにリストされたパッケージの選択。
    2. パッケージ依存関係の解決。
    3. prermスクリプトの実行
    4. 設定ファイルを含めた インストール済みファイルの削除。
    5. postrmスクリプトの実行。

上記では全体像の理解のためにわざと技術詳細を端折っています。

2.1.7. パッケージ管理のトラブルへの応急対処法

内容が正確な正式文書を読むように心がけるべきです。まずDebianに特定のことが記載された"/usr/share/doc/<package_name>/README.Debian"を最初に読むべきです。また"/usr/share/doc/<package_name>/"の中にある他の文書も参照すべきです。「Bashのカスタム化」に書かれたようなシェル設定がされていれば、次のようにタイプしてください。

$ cd <package_name>
$ pager README.Debian
$ mc

さらに詳しい情報を得るには"-doc"というサフィックスを持った対応する文書パッケージをインストールする必要があるかもしれません。

特定のパッケージで問題を経験した際には、次のサイトを確認してください。

表2.6 特定パッケージの問題解決のためのキーとなるウエッブサイトのリスト。

サイト コマンド
Debianバグトラッキングシステム(BTS)のホームページ。 sensible-browser "http://bugs.debian.org/"
既知のパッケージに関するバグレポート。 sensible-browser "http://bugs.debian.org/<package_name>"
既知のバグ番号に関するバグレポート。 sensible-browser "http://bugs.debian.org/<bug_number>"

"site:debian.org"や"site:wiki.debian.org"や"site:lists.debian.org"等を含む検索語でGoogleを検索します。

バグ報告をする際には、reportbug(1)コマンドを使いましょう。

2.2. 基本的パッケージ管理操作

AptitudeはDebianシステムで現在推薦されるパッケージ管理ツールです。apt-get / apt-cacheをコマンドラインで代替もしますし、またフルスクリーンのインタラクティブなパッケージ管理ツールとしても使えます。

パッケージをインストールしたりパッケージのメタデータを更新するようなパッケージ管理操作にはroot権限が必要です。

2.2.1. コマンドラインによる基本的なパッケージ管理操作

aptitude(8)やapt-get(8) /apt-cache(8)を使うコマンドラインによるパッケージ管理操作を次に記します。

表2.7 aptitudeapt-get /apt-cacheを使うコマンドラインによるパッケージ管理操作

aptitudeシンタックス apt-get/apt-cacheシンタックス 説明
aptitude update apt-get update アーカイブメタデータの更新。
aptitude install foo apt-get install foo "foo"パッケージの候補バージョンをその依存関係とともにインストールします。
aptitude safe-upgrade apt-get upgrade 他のパッケージを削除すること無くインストール済みパッケージの候補バージョンをインストールします。
aptitude full-upgrade apt-get dist-upgrade <パッケージ> 必要なら他のパッケージを削除しながらインストール済みパッケージの候補バージョンをインストールします。
aptitude remove foo apt-get remove foo 設定ファイルを残したまま"foo"パッケージを削除します。
N/A apt-get autoremove 既に必要なくなっている自動済みパッケージを削除します。
aptitude purge foo apt-get purge foo 設定ファイルを含めて"foo"パッケージを完全削除します。
aptitude clean apt-get clean 収集されローカルに貯蔵されたパッケージファイルを完全に消去します。
aptitude autoclean apt-get autoclean 収集されローカルに貯蔵されたパッケージファイルのうち古くなったパッケージを消去します。
aptitude show foo apt-cache show <パッケージ> "foo"パッケージに関する詳細情報を表示します。
aptitude search <regex> apt-cache search <regex> <regex>とマッチするパッケージを探す。
aptitude why <regex> N/A なぜ<regex>とマッチするパッケージがインストールされるのかを説明します。
aptitude why-not <regex> N/A なぜ<regex>とマッチするパッケージがインストールされないのかを説明します。

Debianシステム上の異なったパッケージツールを混用しても問題が起こらなくなりましたが、できるだけaptitudeを使い続けるのが最善です。

"safe-upgrade"/"upgrade"や"full-upgrade"/"dist-upgrade"の違いは新しいバージョンのパッケージが該当する古いバージョンと異なった依存関係がある場合にのみ起こります。"aptitude safe-upgrade"コマンドは新規のパッケージをインストールも削除もしません。

"aptitude why <regex>"は"aptitude -v why <regex>"とすることでさらに詳しい情報を表示します。同様の情報は"apt-cache rdepends <package>"とすることでも得られます。

aptitudeコマンドが最初コマンドラインモードで実行されパッケージ間のコンフリクトのような問題に直面した場合は、プロンプトがでた際に"e"を押すことでフルスクリーンのインタラクティブモードに切り替えられます。

"aptitude"のすぐ後ろにコマンドオプションをつけられます。

表2.8 aptitude(8)に関する特記すべきコマンドオプション。

コマンドオプション 説明
-s コマンド結果のシミュレートをします。
-d インストール/アップグレードをせずにダウンロードだけします。
-D 自動的なインストールや削除の前に簡単な説明を表示します。

詳細はaptitude(8)や"/usr/share/doc/aptitude/README"にある"aptitude user's manual"を参照してください。

[ティップ] ティップ

現在でも存続しているdselectパッケージは、過去のリリースでは推薦されたフルスクリーンのインタラクティブなパッケージ管理ツールでした。

2.2.2. aptitudeのインタラクティブな使用

インタラクティブなパッケージ管理のためにはaptitudeをコンソールのシェルからインタラクティブモードで次のように立ち上げます。

$ sudo aptitude -u
Password:

これによりアーカイブ情報のローカルコピーは更新され、フルスクリーンのパッケージリストがメニュー付きで表示されます。Aptitudeの設定ファイルは"~/.aptitude/config"にあります。

[ティップ] ティップ

userの設定ファイルでなくrootの設定ファイルを使いたい際には、上記の例で"sudo aptitude ..."の代わりに"sudo -H aptitude ..."を使いましょう。

[ティップ] ティップ

Aptitudeはインタラクティブに起動されると次にするアクションを自動的に設定します。その設定が好ましくない場合はメニュー:"Action" → "Cancel pending actions"からリセットすることができます。

2.2.3. aptitudeのキーバインディング

パッケージの状態を閲覧し、"予定のアクション"の設定をこのフルスクリーンモードで各パッケージするための重要なキーは次です:

表2.9 aptitudeのキーバインディングのリスト。

キー キーバインディング
F10もしくくはCtrl-t メニュー
? (より詳細な)キーの意味のヘルプの表示
F10 → ヘルプ → ユーザマニュアル ユーザマニュアルの表示
u パッケージアーカイブ情報の更新
+ パッケージをアップグレードまたはインストールするとマークします。
- パッケージを削除するとマークします。(設定ファイルは温存)
_ パッケージを完全削除するとマークします。(設定ファイルも削除)
= パッケージをホールドします。
U 全てのアップグレード可能なパッケージをマークします。(full-upgradeとして機能)
g 選ばれたパッケージのダウンロードインストールを開始します。
q 現在のスクリーンを終了し変更を保存します。
x 現在のスクリーンを終了し変更を廃棄します。
Enter パッケージに関する情報閲覧します。
C パッケージの変更履歴の閲覧します。
l 表示されるパッケージの制限を変更します。
/ 最初のマッチを検索します。
\ 最近の検索を繰り返す。

コマンドラインのファイル名の規定や、"l"や"/"を押した後のメニュープロンプトは次に記すaptitudeのregex(正規表現)が使われます。aptitudeのregexは"~n"で始めそれにパッケージ名を続けた文字列を使うことで明示的にパッケージ名とマッチさせられます。

[ティップ] ティップ

ビジュアルインターフェースで全てのインストール済みパッケージを候補バージョンにアップグレードさせるには"U"を押さなければいけません。これをしないと選ばれたパッケージとそれにバージョン付きの依存関係のある特定のパッケージのみがアップグレードされます。

2.2.4. aptitudeの下でのパッケージの表示

インタラクティブなフルスクリーンモードのaptitude(8)は次のようなデフォルトのパッケージリスト形式でパッケージを表示します。

idA   libsmbclient                             -2220kB 3.0.25a-1  3.0.25a-2

この行は左から次のような意味です:

  • "現状"フラグ(1番目の文字)
  • "予定のアクション"フラグ(2番目の文字)
  • "自動"フラグ(3番目の文字)
  • パッケージ名
  • "予定のアクション"に帰属されるディスクスペースの使用の変化
  • パッケージの現バージョン
  • パッケージの候補バージョン
[ティップ] ティップ

"?"を押して表示されるヘルプスクリーンの一番下に全フラグのリストがあります。

現在のローカルの環境設定によって候補バージョンは選ばれます(apt_preferences(5)と「候補バージョンの調整」を参照)。

"表示"メニューの下に数種のパッケージ表示があります。

表2.10 aptitudeの表示のリスト。

表示 分類 状況
パッケージ画面 表2.11「標準パッケージ画面の分類。」参照下さい。(デフォルト) 良好
推奨を監査 何らかのインストール済みパッケージによって推薦されているがインストールされていないパッケージをリストします。 良好
平坦なパッケージリスト パッケージを分類されずにリストする(regexとともに使うため)。 良好
Debtags表示 パッケージのdebtagsのエントリーにより分類し表示します。 十分使える
カテゴリ別表示 パッケージの分類別に分類表示します。 非推奨 (debtagsを使おう!)

標準"パッケージ画面"はパッケージをdselectにいくつかの機能を加えた感じで分類します。

表2.11 標準パッケージ画面の分類。

分類 構成
更新可能なパッケージ セクション → コンポーネント → パッケージ、という構成
新規パッケージ , ,
インストール済みのパッケージ , ,
インストールされていないパッケージ , ,
廃止された、またはローカルで作成されたパッケージ , ,
仮想パッケージ 同一機能を持ったパッケージの集合から特定のパッケージを選択できる。
タスク 特定タスクのパッケージ集合から特定のパッケージを良いとこ取りで選択できる。

2.2.5. aptitudeを使った探索方法

Aptitudeはそのregex式機能を通してパッケージを探索する方法をいくつか提供します。

  • "aptitude search '<aptitude_regex>'"はマッチするパッケージのインストール状態やパッケージ名や短い説明をリストします。
  • "aptitude show '<package_name>'"はパッケージに関する詳細な説明をリストします。
  • マッチングするパッケージに表示を制限: フルスクリーンモードで"l"とタイプ。
  • 最初にマッチングするパッケージを表示: フルスクリーンモードで"/"とタイプ。"n"で前方探索、"\"で後方探索。

<package_name>という文字列は、"~"で始めてregex式と明示されていない限り、パッケージ名との完全な一致検索として扱います。

2.2.6. aptitudeのregex式

aptitudeのregex式はmutt的な拡張ERE(「正規表現」参照)でaptitudeに特定なマッチ規則の拡張は次に示すとおりです:

表2.12 aptitudeのregex式のリスト。

拡張マッチ規則の意味 regex式
パッケージ名とのマッチ ~n<名前のregex>
記述とのマッチ ~d<記述のregex>
タスク名とのマッチ ~t<タスクのregex>
debtagとのマッチ ~G<debtagのregex>
メンテナとのマッチ ~m<maintainerのregex>
パッケージセクションとのマッチ ~s<セクションのregex>
パッケージバージョンとのマッチ ~V<バージョンのregex>
アーカイブ(archive)とのマッチ ~A{sarge,etch,sid}
オリジン(origin)とのマッチ ~O{debian,…}
優先度(priority)とのマッチ ~p{extra,important,optional,required,standard}
必須(essential)パッケージとのマッチ ~E
仮想パッケージとのマッチ ~v
新規パッケージとのマッチ ~N
次のアクションとのマッチ ~a{install,upgrade,downgrade,remove,purge,hold,keep}
インストール済みパッケージとのマッチ ~i
A-マークのついたインストール済みパッケージとマッチ(自動インストール済みパッケージ) ~M
A-マークのついていないインストール済みパッケージとマッチ(管理者が選択したパッケージ) ~i!~M
インストール済みかつアップグレード可能なパッケージとマッチ ~U
削除済みだが完全削除されていないパッケージとマッチ ~c
削除済みか完全削除済みか削除可能なパッケージとマッチ ~g
パッケージ依存関係が壊れたパッケージとマッチ ~b
depends/predepends/conflictの依存関係が壊れたパッケージとマッチ ~B<type>
<term>パッケージに対して<type>の依存関係があるとパッケージのコントロールファイルに記載されたパッケージとマッチ ~D[<type>:]<term>
<term>パッケージに対して<type>の壊れた依存関係があるとパッケージのコントロールファイルに記載されたパッケージとマッチ ~DB[<type>:]<term>
<term>パッケージに対して<type>の依存関係があるパッケージとマッチ ~R[<type>:]<term>
<term>パッケージに対して<type>の壊れた依存関係があるパッケージとマッチ ~RB[<type>:]<term>
他のインストール済みパッケージが依存するパッケージとマッチ ~R~i
他のインストール済みパッケージが一切依存しないパッケージとマッチ !~R~i
他のインストール済みパッケージが依存もしくは推薦するパッケージとマッチ ~R~i|~Rrecommends:~i
フィルタされたバージョンの<term>とマッチ ~S filter <term>
常に全てのパッケージにマッチ(真) ~T
どのパッケージにもマッチしない(偽) ~F

上記で:

  • regex部分は、"^"や".*"や"$"などを使うegrep(1)やawk(1)やperl(1)といった典型的なUnix的テキストツールで使われるEREと同様です。
  • 関係を表す<type>は(depends, predepends, recommends, suggests, conflicts, replaces, provides)の内の一つです。
  • デフォルトの関係は"depends"です。
[ティップ] ティップ

<regex_pattern>がヌル文字列の場合は"~T"をコマンドの直後に使ってください。

近道:

  • "~P<term>" == "~Dprovides:<term>"
  • "~C<term>" == "~Dconflicts:<term>"
  • "…~W term" == "(…|term)"

muttが表現のお手本なので、muttに慣れているユーザはすぐ慣れるでしょう。"User's Manual" ("/usr/share/doc/aptitude/README")中の"SEARCHING, LIMITING, AND EXPRESSIONS"を参照下さい。

[注意] 注意

lennyバージョンのaptitude(8)では、新規の"?broken"のような長形式のregexマッチ形式が、古い"~b"のような短形式のマッチ形式に代えて使えます。そのためチルダ文字"~"二加えてスペース文字" "もregexの終端文字として扱われます。新規の長形式のマッチ形式については"User's Manual"を参照下さい。

2.2.7. aptitudeによる依存関係の解決

aptitudeによるパッケージの選択は、"F10 → Options → Dependency handling"のメニュー設定に従って、"Depends:"リストに規定されたパッケージばかりでは無く"Recommends:"リストに規定されたパッケージも引き込みます。このような自動的にインストールされたパッケージは不要になるとaptitudeが自動的に削除します。

[注意] 注意

lennyリリース以前は、apt-get等の他の標準的なAPTツールは自動的削除機能がありませんでした。

2.2.8. パッケージアクティビティーログ

パッケージアクティビティーの履歴はログファイルで確認できます。

表2.13 パッケージアクティビティーのログファイル

ファイル 内容
/var/log/dpkg.log 全パッケージアクティビティーのdpkgレベルのアクティビティーのログ
/var/log/apt/term.log APTアクティビティーのログ
/var/log/aptitude aptitudeコマンドアクティビティーのログ

これらのログから意味のある理解を迅速に得るのは実際には難しいです。より簡単な方法については「設定ファイルの変更記録」を参照下さい。

2.2.9. Aptitudeの長所

Aptitudeは他のAPT準拠のパッケージシステム(apt-get, apt-cache, synaptic, …)と比べて次の有利な点があります:

  • aptitudeは独自の追加層(/var/lib/aptitude/pkgstates)を使用して自動インストールされ使われなくなったパッケージを自動的に削除します。(新しいlennyでは、他のAPTも同様のことをします。)
  • aptitudeを使うことでパッケージ間のコンフリクト解消や推薦パッケージの追加がしやすくなります。
  • aptitudeを使うことで"廃止された、またはローカルで作成されたパッケージ"の下にリストすることで廃止ソフトウェアを追跡がしやすくなります。
  • aptitudeは"/var/log/aptitudeにその履歴記録を残します。
  • aptitudeを使うことで利用可能な全てのバージョンのパッケージにアクセスできます。
  • aptitudeには特定パッケージを探したり表示を制限するためのかなり強力なregexシステムがあります。
  • フルスクリーンモードのaptitudesu機能がついているので本当に管理権限が必要になるまでは通常のユーザからの実行ができます。

古いetchリリースのバージョンでは、synapticにも履歴記録はありましたが、dpkgの記録に頼らなければapt-getには履歴記録はありませんでした。

何れにせよaptitudeはコンソールでのインタラクティブな使用に好適です。

2.3. aptitude操作例

aptitude(8)操作例を次に示します。

2.3.1. regexにマッチするパッケージ名のパッケージをリスト

次のコマンドはregexにマッチする名前のパッケージをリストします。

$ aptitude search '~n(pam|nss).*ldap'
p libnss-ldap - NSS module for using LDAP as a naming service
p libpam-ldap - Pluggable Authentication Module allowing LDAP interfaces

これはパッケージの正確な名前を探すときに非常に便利です。

2.3.2. regexマッチをして閲覧

"平坦なパッケージリスト"のビューで"l"のプロンプトにregex"~dipv6"を入れるとその意味にマッチするパッケージにビューが制限され、その情報をインタラクティブに閲覧できます。

2.3.3. パッケージを本当に完全削除

削除したパッケージが残した全ての設定ファイルを完全削除できます:

# aptitude search '~c'
  • 結果の確認
# aptitude purge '~c'

同様のことをインタラクティブにすればよりきめの細かい結果が得られます。

"平坦なパッケージリスト"のビューで"l"のプロンプトにregex"~c"を入れるとregexにマッチする"削除されたが完全さ駆除されていない"パッケージにビューが制限されます。トップレベルの見出しの上で"["を押すとregexにマッチする全てのパッケージが表示されます。

次に"インストール済みのパッケージ"等のトップレベルの見出しの上で"_"を押します。その見出しの下のregexにマッチするパッケージだけが完全削除と設定されます。インタラクティブに個々のパッケージの上で"="を押せばそれらのパッケージを完全削除対象から外せます。

このテクニックは非常に便利で、他の多くのコマンドキーでも使えます。

2.3.4. 自動/手動インストールの状態の整理

(非aptitudeのパッケージインストーラー等を使った後で)パッケージの自動/手動インストールの状態を整理する私の方法を次に記します:

  • aptitudeをrootとしてインタラクティブに起動します。
  • "u"と"U"と"f"と"g"とタイプしてパッケージリストを更新しパッケージをアップグレードします。
  • "l"とタイプしてパッケージ表示制限を"~i(~R~i|~Rrecommends:~i)"として、"インストール済みのパッケージ"の上で"M"とタイプして自動インストールされたとします。
  • "l"とタイプしてパッケージ表示制限を"~prequired|~pimportant|~pstandard|~E"として、"インストール済みのパッケージ"の上で"m"とタイプして手動インストールされたとします。
  • "l"とタイプしてパッケージ表示制限を"~i!~M"として、"インストール済みのパッケージ"の上で"["とタイプしてパッケージを見えるようにした後で個々のパッケージの上で"-"とタイプして使っていないパッケージを削除します。
  • "l"とタイプしてパッケージ表示制限を"~i(~R~i|~Rrecommends:~i)"として、"インストール済みのパッケージ"の上で"M"とタイプして自動インストールされたとします。
  • aptitudeを終了。
  • "apt-get -s autoremove|less"とrootから起動して何が使われていないのか確認します。
  • aptitudeとインタラクティブモードで起動して必要なパッケージを"m"でマークします。
  • "apt-get -s autoremove|less"とrootから再起動して削除対象が期待にかなっていることを再確認します。
  • "apt-get autoremove|less"とrootから起動して使用していないパッケージを自動削除します。

"Tasks"の上で"m"を押すのも一案で、大量ファイル除去となる事態が回避できます。

2.3.5. aptitudeを使ったシステム全体のアップグレード

[注意] 注意

新しいリリース等への移行は、Debianでは下記のようにアップグレードできるのですが、新たなシステムをクリーンインストールすることを考えるべきです。こうすると溜めてきたゴミの除去ができる上に最新のパッケージの最良の組み合わせも分かります。もちろん安全な場所に完全なシステムのバックアップ(「Backup and recovery」参照)を事前にしなくてはいけません。異なったパーティションを使ったデュアルブート設定をすることをスムーズな移行をするためにお薦めします。

"/etc/apt/sources.list"ファイルの内容を新しいリリースへと向けるように変更し、"aptitude update; aptitude full-upgrade"コマンドを実行することでシステム全体のアップグレードができます。

安定版stableからテスト版testingや不安定版unstableにアップグレードするには、「Debianアーカイブの基本」にある"/etc/apt/sources.list"例の"lenny"を"squeeze"か"sid"に置き換えます。

一部のパッケージで移行に関して支障をきたすことが実際には起こるかもしれません。これは大体パッケージ依存関係に起因します。アップグレードする差が大きければ大きいほど比較的大きな問題似合う可能性がより大きくなります。以前の安定版stableからリリース後の新しい安定版stableへの移行では新しいリリースノートを読んでそこに記載された手続き通りに完全にすれば問題発生を防げます。

安定版stableからテスト版testingへ移行すると決めた時には頼りにするリリースノートはありません。前回の安定版stableのリリースの後で安定版stableとテスト版testingの差がかなり大きくなっているかもしれません。そうだとアップグレードをする状況は複雑になっています。

メーリングリストから最新情報を収集するとか常識を使うといった予防措置をするべきです。

  • 前回の"リリースノート"を読む。
  • 全システム(特にデータや設定情報)をバックアップします。
  • ブートローダが壊れたときのためにブートできる媒体を確保します。
  • システムを使っているユーザに十分事前に通告します。
  • script(1)を使ってアップグレード活動を記録します。
  • 削除をされないように"aptitude unmarkauto vim"等として、"unmarkauto"を重要なパッケージに適用します。
  • デスクトップタスクにあるパッケージ等を削除して、インストールされたパッケージを減らしてパッケージがコンフリクトする可能性を減らす。
  • "/etc/apt/preferences"ファイルを削除します。(apt-pinningを無効にする)
  • 段階的にアップグレードするように努める:旧安定版oldstable → 安定版stable → テスト版testing → 不安定版unstable
  • "/etc/apt/sources.list"ファイルをアップデートして新しいアーカイブに向けて、"aptitude update"を実行します。
  • "aptitude install perl"等として、新規の中核的パッケージのインストールを必要に応じて先にします。
  • "aptitude full-upgrade -s"コマンドを実行して影響を確認する。
  • "aptitude full-upgrade"コマンドを実行します。
[注意] 注意

stableリリース間でアップグレードする際にDebianのメジャーリリースを飛ばすのは賢明ではない。

[注意] 注意

過去の"リリースノート"ではシステム全体のアップグレードをするのにGCCやLinuxカーネルやinitrd-toolsやGlibcやPerlやAPT tool chain等には特別な配慮が必要でした。

unstableでの毎日のアップグレードは「パッケージの問題に対する防御」を参照下さい。

2.4. 高度なパッケージ管理操作

2.4.1. コマンドラインによる高度なパッケージ管理操作

aptitudeではハイレベル過ぎるとか必要な機能を欠くという他のパッケージ管理操作のリストです。

表2.14 高度なパッケージ管理操作のリスト

アクション コマンド
バグレポートのためのにインストールされたパッケージの状態をリストします。 COLUMNS=120 dpkg -l <パッケージ名パターン>
インストールされたパッケージの内容をリストします。 dpkg -L <パッケージ名>
インストールされたパッケージのmanページをリストします。 dpkg -L <パッケージ名> | egrep '/usr/share/man/man.*/.+'
マッチするファイル名があるインストールされたパッケージをリストします。 dpkg -S <ファイル名パターン>
マッチするファイル名があるアーカイブ中のパッケージをリストします。 apt-file search <ファイル名パターン>
アーカイブ中のマッチするパッケージをリストします。 apt-file list <パッケージ名パターン>
特定パッケージを再設定します。 dpkg-reconfigure <パッケージ名>
もっとも詳細な質問で特定パッケージを再設定します。 dpkg-reconfigure -p=low <パッケージ名>
フルスクリーンメニューからパッケージを再設定します。 configure-debian
部分的にインストールされたパッケージに関してシステムを監査します。 dpkg --audit
全ての部分的にインストールされたパッケージを設定します。 dpkg --configure -a
バイナリパッケージに関して使用可能なバージョンやプライオリティーやアーカイブ情報を表示します。 apt-cache policy <バイナリパッケージ名>
パッケージに関して使用可能なバージョンやアーカイブ情報を表示します。 apt-cache madison <パッケージ名>
バイナリパッケージに関してソースパッケージの情報を表示します。 apt-cache showsrc <バイナリパッケージ名>
パッケージをビルドするのに必要なパッケージをインストールします。 apt-get build-dep <パッケージ名>
(標準アーカイブから)ソースをダウンロードします。 apt-get source <パッケージ名>
(他のアーカイブから)ソースをダウンロードします。 dget <dscファイルのURL>
ソースパッケージの組("*.tar.gz"と"*.diff.gz")からソースツリーをビルドします。 dpkg-source -x <パッケージ名>_<バージョン>-<debianバージョン>.dsc
ローカルのソースツリーからパッケージをビルドします。 debuild binary
カーネルソースツリーからカーネルパッケージをビルドします。 make-kpkg kernel_image
カーネルソースツリーからinitramfsを有効にしてカーネルパッケージをビルドします。 make-kpkg --initrd kernel_image
ローカルパッケージをシステムにインストールします。 dpkg -i <パッケージ名>_<バージョン>-<debianバージョン>_<アーキテクチャー名>.deb
ローカルパッケージ(複数)をシステムにインストールします。 debi <パッケージ名>_<バージョン>-<debianバージョン>_<アーキテクチャー名>.dsc
dpkgレベルのパッケージ選択状態情報を保存します。 dpkg --get-selection '*' >selection.txt
dpkgレベルのパッケージ選択状態情報を設定します。 dpkg --set-selection <selection.txt

[注意] 注意

"dpkg -i …"や"debi …"といった低いレベルのパッケージツールはシステム管理者によって注意深く使われなければいけません。必要なパッケージ依存関係を自動的に面倒見てくれません。Dpkgの"--force-all"や類似のコマンドラインオプション(dpkg(1)参照)はエキスパートだけが使うようにできています。十分にその影響を理解せずに使うとシステム全体を壊してしまうかもしれません。

次に注意下さい:

  • 全てのシステム設定やインストールコマンドはrootから実行なければいけません。
  • regex(「正規表現」参照)を使うaptitudeと異なり、他のパッケージ管理コマンドはシェルグロブ(「シェルグロブ」参照)のようなパターンを使います。
  • apt-fileパッケージに入っているapt-file(1)は事前に"apt-file update"を実行する必要があります。
  • configure-debianパッケージに入っているconfigure-debian(8)はそのバックエンドとしてdpkg-reconfigure(8)を実行します。
  • dpkg-reconfigure(8)はそのバックエンドとしてdebconf(1)を利用するパッケージスクリプトを実行します。
  • "apt-get build-dep"や"apt-get source"や"apt-cache showsrc"コマンドは"/etc/apt/sources.list"の中に"deb-src"エントリーが必要です。
  • dget(1)やdebuild(1)やdebi(1)はdevscriptsパッケージが必要です。
  • "apt-get source"を使った(再)パッケージ化の手続きは「安定版システムへのパッケージ移植」を参照下さい。
  • make-kpkgコマンドはkernel-packageパッケージが必要です(「カーネル」参照)。
  • 一般的なパッケージ化に関しては「Debianパッケージ作成」を参照下さい。
[ティップ] ティップ

ソースパッケージの組としてここで説明したソースパッケージのフォーマット("*.tar.gz"と"*.diff.gz")はまだ主流の1.0フォーマットです。他の新規フォーマットに関しての詳細はdpkg-source(1)を参照下さい。

2.4.2. インストールされたパッケージファイルの検証

debsumsをインストールするとdebsums(1)を使って"/var/lib/dpkg/info/*.md5sums"ファイル中のMD5sum値との比較でインストールされたパッケージファイルを検証できます。MD5sumがどのような仕組かは「The MD5 sum」参照ください。

[注意] 注意

侵入者によってMD5sumのデータベースが改竄されているかもしれないのでdebsums(1)はセキュリティツールとしては限定的有用性しかありません。管理者によるローカルの変更や記憶媒体のエラーによる損傷を点検するぐらいには有用です。

2.4.3. パッケージの問題に対する防御

多くのユーザは新しい機能やパッケージを求めてDebianシステムの非安定版unstableリリースを追いかけることを好みます。こういうことをするとクリティカルなパッケージのバグにシステムが遭遇しやすくなります。

apt-listbugsパッケージをインストールすれば、APTシステムを使ってアップグレードする時にDebianのBTSを自動的にクリティカルなバグに関して点検することで、クリティカルなバグから防御ができます。

apt-listchangesパッケージをインストールすれば、APTシステムを使ってアップグレードする時にNEWS.Debian中の重要ニュースを表示します。

2.4.4. パッケージメタデータの検索

最近はDebianサイトのhttp://packages.debian.org/を訪問するとパッケージメタデータの検索を簡単に出きるようになっていますが、より伝統的な方法を見てみましょう。

grep-dctrl(1)やgrep-status(1)やgrep-available(1)コマンドはDebianのパッケージコントロールファイルの一般的フォーマットに従ういかなるファイルを検索するのにも使えます。

マッチする名前のファイルを含むdpkgでインストールされたパッケージ名を探索するのに"dpkg -S <ファイル名パターン>"が使えます。しかしメンテナスクリプトで生成されるファイルはこれでは見逃されます。

dpkgのメタデータに関するより詳細な検索をする必要がある場合、"/var/lib/dpkg/info/"ディレクトリで"grep -e regexパターン *"コマンドを実行しないといけません。こうすることで次のことが分かります:

  • パターンにマッチする特定ファイルをインストールや作成や改変するパッケージ名。
  • パターンにマッチするインストールの質問文言を聞くパッケージ名。

パッケージ依存関係を再帰的に検索したい際には、apt-rdepends(8)を使いましょう。

2.5. Debianパッケージ管理の内部

Debianのパッケージ管理システムが内部的のどのように機能するのかを学びましょう。何らかのパッケージ問題が発生した際にあなた自身の解決を見出すのに役立つでしょう。

2.5.1. アーカイブのメタデータ

各ディストリビューションのメタデータのファイルは例えば"http://ftp.us.debian.org/debian/"のような各Debianミラーサイトの"dist/<コード名>"の下に保存されています。そのアーカイブ構造はウエッブブラウザで閲覧できます。6つのタイプの重要メタデータがあります:

表2.15 Debianアーカイブのメタデータの内容。

ファイル 場所 内容
Release ディストリビューションのトップ アーカイブの説明との整合性情報
Release.gpg ディストリビューションのトップ アーカイブキーで署名された"Release"ファイルに関する署名ファイル
Contents-<アーキテクチャー> ディストリビューションのトップ 該当アーカイブ中全てのパッケージに関する全ファイルリスト
Release 各ディストリビューション/コンポーネント/アーキテクチャーの組み合わせのトップ apt_preferences(5)のルールに利用されるアーカイブの記述。
Packages 各ディストリビューション/コンポーネント/バイナリアーキテクチャーの組み合わせのトップ バイナリパッケージに関してdebian/controlを連結
Sources 各ディストリビューション/コンポーネント/ソースの組み合わせのトップ ソースパッケージに関してdebian/controlを連結

最近のアーカイブではネットワークトラフィックを減らすべく圧縮された差分ファイルとしてこれらのメタデータは保存されています。

2.5.2. トップレベルの"Release"ファイルと信憑性

[ティップ] ティップ

セキュアAPTシステムではトップレベルの"Release"ファイルがアーカイブを署名するのに使われています。

Debianアーカイブの各スイーツには例えば"http://ftp.us.debian.org/debian/dists/unstable/Release"のようなトップレベルの"Release"ファイルがあります。

Origin: Debian
Label: Debian
Suite: unstable
Codename: sid
Date: Sat, 26 Jan 2008 20:13:58 UTC
Architectures: alpha amd64 arm hppa hurd-i386 i386 ia64 m68k mips mipsel powerpc s390 sparc
Components: main contrib non-free
Description: Debian x.y Unstable - Not Released
MD5Sum:
 e9f11bc50b12af7927d6583de0a3bd06 22788722 main/binary-alpha/Packages
 43524d07f7fa21b10f472c426db66168  6561398 main/binary-alpha/Packages.gz
...
[注意] 注意

「Debianアーカイブの基本」の中で"スイーツ(suite)"や"コード名(codename)"や"コンポーネント(component)"を使う理由はこれを見れば分かるでしょう。"ディストリビューション"は"スイーツ"と"コード名"との両方を指したい際に用いられます。

トップレベルの"Release"ファイルの整合性は セキュアaptという暗号学手法インフラストラクチャーによって検証されます。

  • 暗号手法による署名ファイル"Release.gpg"は真正のトップレベルの"Release"ファイルと秘密のDebianアーカイブキーから作成されます。
  • 公開のDebianアーカイブキーは"/etc/apt/trusted.gpg"に取り込むには次のようにします:

  • セキュアAPTシステムはこの"Release.gpg"ファイルと"/etc/apt/trusted.gpg"中の公開アーカイブキーを用いてダウンロードされたトップレベルの"Release"ファイルの整合性を暗号学手法を用いて検証します。

"全てのPackages"と"Sourcesファイルの整合性はそのトップレベルの"Release"ファイル中のMD5sum値を用いて検証します。"パッケージファイルの整合性は"Packages"や"Sources"ファイル中のMD5sum値を用いて検証します。debsums(1)と「インストールされたパッケージファイルの検証」を参照下さい。

暗号学手法を用いた署名の検証はMD5sum値の計算よりも非常にCPUを使うプロセスなので、トップレベルの"Release"ファイルには暗号学手法を用いた署名を使いつつ各パッケージにはMD5sum値を用いることでパーフォーマンスを保ったまま良好なセキュリティが確保できます(「Data security infrastructure」参照)。

2.5.3. アーカイブレベルの"Release"ファイル

[ティップ] ティップ

アーカイブレベルの"Release"ファイルはapt_preferences(5)のルールに利用されます。

"http://ftp.us.debian.org/debian/dists/unstable/main/binary-amd64/Release"や"http://ftp.us.debian.org/debian/dists/sid/main/binary-amd64/Release"等の"/etc/apt/sources.list"中の"deb"行で特定される全てのアーカイブロケーションにはアーカイブレベルの"Release"ファイルがあります。

Archive: unstable
Component: main
Origin: Debian
Label: Debian
Architecture: amd64
[注意] 注意

"Archive:"スタンザには、Debianアーカイブではスイート名("stable"や"testing"や"unstable"等)が使われますが、Ubuntuアーカイブではコード名("dapper"や"feisty"や"gutsy"や"hardy"や"intrepid"等)が使われます。

experimentalvolatile-sloppylenny-backportsのような自動的にインストールされるべきでないパッケージを含むようなアーカイブでは"http://ftp.us.debian.org/debian/dists/experimental/main/binary-amd64/Release"のような追加の行があります:

Archive: experimental
Component: main
Origin: Debian
Label: Debian
NotAutomatic: yes
Architecture: amd64

"NotAutomatic: yes"となっていない通常のアーカイブではデフォルトのPin-Priority値は500ですが、"NotAutomatic: yes"となっている特別なアーカイブではデフォルトのPin-Priority値は1です(apt_preferences(5)と「候補バージョンの調整」参照)。

2.5.4. パッケージメタデータの取得

aptitudeapt-getsynapticapt-fileauto-apt等のAPTツールが使われる際にはDebianアーカイブ情報を含むメタデータのローカルコピーを更新する必要があります。この様なコピーは"/etc/apt/sources.list"中のディストリビューションコンポーネントアーキテクチャーの名前に対応する次のファイル名です(「Debianアーカイブの基本」参照):

  • "/var/lib/apt/lists/ftp.us.debian.org_debian_dists_<ディストリビューション>_Release"
  • "/var/lib/apt/lists/ftp.us.debian.org_debian_dists_<ディストリビューション>_Release.gpg"
  • "/var/lib/apt/lists/ftp.us.debian.org_debian_dists_<ディストリビューション>_<コンポーネント>_source_Sources"
  • "/var/lib/apt/lists/ftp.us.debian.org_debian_dists_<ディストリビューション>_<コンポーネント>_source_Sources"
  • "/var/cache/apt/apt-file/ftp.us.debian.org_debian_dists_<ディストリビューション>_Contents-<アーキテクチャー>.gz" (apt-file用)

最初の4つのタイプのファイルは全ての適切なAPTコマンド間で共有されておりコマンドラインから"apt-get update"や"aptitude update"によって更新されます。もし"/etc/apt/sources.list"中に"deb"行があれば"Packages"メタデータが更新されます。もし"/etc/apt/sources.list"中に"deb-src"行があれば"Sources"メタデータが更新されます。

"Packages"や"Sources"メタデータはバイナリやソースパッケージのファイルの場所を指している"Filename:"スタンザを含んでいます。現在、それらのパッケージはリリース間の移行を滞り無くするために"pool/"ディレクトリツリーの下に置かれています。

"Packages"メタデータのローカルコピーはaptitudeを使ってインタラクティブに検索できます。grep-dctrl(1)という専用の検索コマンドを使うと"Packages"と"Sources"メタデータのローカルコピーを検索できます。

"Contents-<アーキテクチャー>"メタデータのローカルコピーは"apt-file update"で更新でき、他の4つと異なるところにあります。apt-file(1)を参照下さい。(auto-aptでは"Contents-<アーキテクチャー>.gz"のローカルコピーがデフォルトでは異なるところにあります。)

2.5.5. APTに関するパッケージ状態

lenny以降のAPTツールではリモートから取得したメタデータに追加でローカルで生成されるインストール状態情報を"/var/lib/apt/extended_states"に保存して、自動インストールされた全パッケージを全てのAPTツールで追跡するのに用います。

2.5.6. aptitudeに関するパッケージ状態

aptitudeコマンドではリモートから取得したメタデータに追加でローカルで生成されるインストール状態情報を"/var/lib/aptitude/pkgstates"に保存して用いています。

2.5.7. 取得したパッケージのローカルコピー

APTメカニズムでリモートから取得されたパッケージは消去されるまでは"/var/cache/apt/packages"に貯蔵されます。

2.5.8. Debianパッケージファイル名

Debianのパッケージファイルには特定の名前の構造があります。

表2.16 Debianパッケージの名前の構造。

パッケージタイプ 名前の構造
バイナリパッケージ(所謂deb) <パッケージ名>_<エポック>:<アップストリームのバージョン>-<debianのバージョン>-<アーキテクチャー>.deb
debianインストーラーのためのバイナリパッケージ(所謂udeb) <パッケージ名>_<エポック>:<アップストリームのバージョン>-<debianのバージョン>-<アーキテクチャー>.udeb
ソースパッケージ(アップストリームのソース) <パッケージ名>_<エポック>:<アップストリームのバージョン>-<debianのバージョン>.tar.gz
ソースパッケージ(Debianの変更部分) <パッケージ名>_<エポック>:<アップストリームのバージョン>-<debianのバージョン>.diff.gz
ソースパッケージ(内容記述) <パッケージ名>_<エポック>:<アップストリームのバージョン>-<debianのバージョン>.dsc

ここで、

表2.17 Debianパッケージ名の各部分に使用可能な文字。

名前の部分 使用可能文字(regex) 存在
<パッケージ名> [a-z,A-Z,0-9,.,,-] 必須
<エポック>: [0-9]+: 任意
<アップストリームのバージョン> [a-z,A-Z,0-9,.,,-,:] 必須
<debianのバージョン> [a-z,A-Z,0-9,.,,~] 任意

[注意] 注意

パッケージバージョンの順位はdpkg(1)を使って、例えば"dpkg --compare-versions 7.0 gt 7.~pre1 ; echo $?"とすると確認できます。

[注意] 注意

Debianインストーラー(d-i)のバイナリパッケージには、通常のdebではなくudebをファイルエクステンションとして使われます。udebパッケージはポリシー条件を緩和しドキュメントのように必須でない内容を削除した減量debパッケージです。debudebパッケージは同一のパッケージ構造を共有しています。"u"はマイクロと言う意味で使っています。

2.5.9. dpkgコマンド

dpkg(1)はDebianパッケージ管理の最も低レベルのツールです。非常に強力ですから気をつけて使う必要があります。

取得されたパッケージはdpkgによって次の順で処理されます:

  1. debファイルを解凍("ar -x"と等価)
  2. debconf(1)を使ったpreinst
  3. システムにパッケージ内容をインストール("tar -x"と等価)
  4. debconf(1)を使ったpostinst

debconfシステムによってI18NとL10N(8章I18N and L10N)のサポートのある標準化されたユーザとの対話が実現できます。

"<パッケージ名>"というパッケージをインストールする際にdpkgはファイルをいくつか作りスクリプトをいくつか実行します。

表2.18 dpkgに関する特記すべきファイル。

ファイル 内容
/var/lib/dpkg/info/<パッケージ名>.conffiles 設定ファイルのリスト。(ユーザ変更可能)
/var/lib/dpkg/info/<パッケージ名>.list パッケージによりインストールされるファイルやディレクトリのリスト。
/var/lib/dpkg/info/<パッケージ名>.md5sums パッケージによりインストールされるファイルのMD5ハッシュ値のリスト。
/var/lib/dpkg/info/<パッケージ名>.preinst パッケージ導入の前に実行するパッケージスクリプト。
/var/lib/dpkg/info/<パッケージ名>.postinst パッケージ導入の後に実行するパッケージスクリプト。
/var/lib/dpkg/info/<パッケージ名>.prerm パッケージ削除の前に実行するパッケージスクリプト。
/var/lib/dpkg/info/<パッケージ名>.prerm パッケージ削除の前に実行するパッケージスクリプト。
/var/lib/dpkg/info/<パッケージ名>.conffiles debconfシステムのためのパッケージスクリプト。
/var/lib/dpkg/alternatives/<パッケージ名> update-alternativesコマンドが用いる代替情報。
/var/lib/dpkg/available すべてのパッケージの入手可能性情報。
/var/lib/dpkg/diversions dpkg(1)に用いられ、dpkg-divert(8)が設定する迂回情報。
/var/lib/dpkg/statoverride dpkg(1)に用いられ、dpkg-statoverride(8)が設定する状態の上書き情報。
/var/lib/dpkg/status パッケージに関する情報閲覧します。
/var/lib/dpkg/status-old "var/lib/dpkg/status"ファイルの第一世代のバックアップ。
/var/backups/dpkg.status* "var/lib/dpkg/status"ファイルの第二世代以前のバックアップ。

"status"ファイルはdpkg(1)や"dselect update"や"apt-get -u dselect-upgrade"のようなツールによって使われます。

grep-dctrl(1)という専用の検索コマンドを使うと"status"と"available"メタデータのローカルコピーを検索できます。

[ティップ] ティップ

デビアンインストーラー 環境下では、udpkgコマンドがudebパッケージを開けるのに用いられます。udpkgコマンドはストリップダウンされたバージョンのdpkgコマンドです。

2.5.10. update-alternativeコマンド

Debianシステムにはupdate-alternatives(8)を用いて何らかの重畳するプログラムを平和裏にインストールするメカニズムがあります。例えばvimnviの両方のパッケージがインストールされた状況下でviコマンドがvimを選択して実行するようにできます。

$ ls -l $(type -p vi)
lrwxrwxrwx 1 root root 20 2007-03-24 19:05 /usr/bin/vi -> /etc/alternatives/vi
$ sudo update-alternatives --display vi
...
$ sudo update-alternatives --config vi
  Selection    Command
 ----------------------------------------------
      1        /usr/bin/vim
*+    2        /usr/bin/nvi

Enter to keep the default[*], or type selection number: 1

Debianの代替(alternatives)システムは、その選択を"/etc/alternatives/"の中のシムリンクとして保持します。選択プロセスには"/var/lib/dpkg/alternatives/"の中の対応するファイルが使われます。

2.5.11. dpkg-statoverrideコマンド

dpkg-statoverride(8)コマンドで提供される状態の上書きは、パッケージをインストールする際にファイルに関して異なる所有者やモードを使うようdpkg(1)に指示する方法です。もし"--update"が指定されファイルが存在すれば、即座に新たな所有者やモードに設定されます。

[注意] 注意

パッケージが所有するファイルの所有者やモードをシステム管理者がchmodchownコマンドを用いて直接変更しても次のパッケージアップグレードがリセットします。

[注意] 注意

ここでファイルと言いましたが、実際にはdpkgが扱うディレクトリやデバイス等のいかなるファイルシステムオブジェクトであってもいいです。

2.5.12. dpkg-divertコマンド

dpkg-divert(8)コマンドによって提供されるファイル迂回は、ファイルをデフォルトの場所ではなく迂回した場所にインストールするようにdpkg(1)にさせます。dpkg-divertは本来パッケージメインテナンススクリプトのためのものです。システム管理者がこれを使うのはお薦めしません。

2.6. 壊れたシステムからの回復

非安定(unstable)システムを動かす時には、管理者は壊れたパッケージ管理状況から回復できることが望ましいです。

[注意] 注意

ここで説明するいくつかの方法は非常にリスクが高いアクションです。警告しましたよ!

2.6.1. 古いユーザの設定との非互換性

もしデスクトップGUIプログラムが上流の大きなバージョンアップグレードの後に不安定性を経験した際には、そのプログラムが作った古いローカル設定ファイルとの干渉を疑うべきです。もし新規作成したユーザアカウントでそのプログラムが安定なら、この仮説が裏付けられます。(これはパッケージングのバグで、通常パッケージャーによって回避されます。)

安定性を回復するには、対応するローカル設定ファイルを移動しGUIプログラムを再スタートします。後日設定情報を回復するために古い設定ファイルの内容を読む必要があるかもしれません。(あまり慌てて消去しないようにしましょう。)

2.6.2. 重複するファイルを持つ相異なるパッケージ

aptitude(8)やapt-get(1)等の、アーカイブレベルのパッケージ管理システムはパッケージの依存関係を使って重複するファイルを持つファイルのインストールしようとさえしません(「パッケージ依存関係」参照)。

パッケージメインテナによるエラーや、システム管理者による不整合な混合ソースのアーカイブの採用(「混合したアーカイブソースからのパッケージ」参照)があった場合には、パッケージ依存関係が誤って定義される事態が発生するかもしれません。そういう状況下で重複するファイルを持つパッケージをaptitude(8)やapt-get(1)を使ってインストールしようとすると、パッケージを展開するdpkg(1)は既存ファイルを上書きすることなく呼ばれたプログラムにエラーを確実に返します。

[注意] 注意

第三者が作成したパッケージを使うと、root権限で実行されるシステムに関して何でもできるメンテナスクリプトが実行されるので、システムが重大なリスクにさらされます。dpkg(1)はパッケージを展開するするさいに上書きする事を防止するだけです。

そのような壊れたインストール状況は、まず古い問題の原因となっているパッケージ<old-package>をまず削除することで回避できます:

$ sudo dpkg -P <old-package>

2.6.3. 壊れたパッケージスクリプトの修正

パッケージスクリプト内のコマンドが何らかの理由でエラーを返しスクリプトがエラーで終了した場合には、パッケージ管理システムは動作を途中終了するので部分的にインストールされたパッケージのある状況が生まれます。パッケージがその削除スクリプト内にバグを持つ場合には、パッケージが削除不能になりうるので大変厄介です。

"<パッケージ名>"のパッケージスクリプトの問題に関しては、以下を確認する必要があります:

  • "/var/lib/dpkg/info/<パッケージ名>.preinst"
  • "/var/lib/dpkg/info/<パッケージ名>.postinst"
  • "/var/lib/dpkg/info/<パッケージ名>.prerm"
  • "/var/lib/dpkg/info/<パッケージ名>.prerm"

rootからスクリプトの問題源の部分を次のように編集します:

  • 行頭に"#"を挿入、または
  • 行末に"|| true"を挿入します。

全ての部分的にインストールされたパッケージを設定します。

# dpkg --configure -a

2.6.4. dpkgコマンドを使っての救済

dpkgは非常に低レベルのパッケージツールなのでネットワーク接続もないブート不能な非常に劣悪な状況下でも機能します。fooパッケージが壊れていて置き換える必要があると仮定しましょう。

バグの無い古いバージョンのfooパッケージが"/var/cache/apt/archives/"にあるパッケージキャッシュの中に見つかるかもしれません。(ここにみつからなければ、http://snapshot.debian.net/アーカイブからダウンロードしたり、機能している機器のパッケージキャッシュからコピーできます。)

もしブート不可能な場合には、次のようにしてインストールすることもできます:

# dpkg -i /path/to/foo_<old_version>_<arch>.deb
[ティップ] ティップ

システムがそれほど壊れていないなら、「緊急ダウングレード」に書かれているようにして、より高レベルのAPTシステムを通じてシステム全体をダウングレードする手もあります。

ハードディスクからブートできない場合には、他の方法でのブートをするようにしましょう。例えば、次の手順をとります:

  • デビアンインストーラー(debian-installer)のCDを使ってレスキューモードでブートします。
  • ブートできないハードディスク上のシステムを"/target"にマウントします。
  • 古いバージョンのfooパッケージを次のようにしてインストールします。
# dpkg --root /target -i /path/to/foo_<old_version>_<arch>.deb

2番めの例は、たとえハードディスク上のdpkgコマンドが壊れていても機能します。

[ティップ] ティップ

ハードディスク上の別のシステムであれ、GNU/LinuxのライブCDであれ、ブート可能なUSBキードライブであれ、ネットブートであれ、どのように起動されたGNU/Linuxシステムでも同様にして壊れたシステムを救済するのに使えます。

もしこの方法でパッケージをインストールしようとして何らかの依存関係違反のためにうまくいかなくてどうしようもなくなった場合には、dpkgの"--ignore-depends"や"--force-depends"や他のオプションを使って依存関係をオーバーライドすることができます。こうした場合には、後で依存関係を修復するように真剣に取り組む必要があります。詳細はdpkg(8)を参照下さい。

[注意] 注意

システムがひどく壊れた場合には、システムを安全な場所に完全バックアップし(「Backup and recovery」参照)、クリー(see 「Backup and recovery」)ンインストールを実行するべきです。こうすることは時間お節約でもあり最終的に良い結果に結びつきます。

2.6.5. パッケージセレクションの回復

もし何らかの理由で"/var/lib/dpkg/status"の内容が腐った場合には、Debianシステムはパッケージ選択データが失われ大きな打撃を被ります。古い"/var/lib/dpkg/status"ファイルは、"/var/lib/dpkg/status-old"や"/var/backups/dpkg.status.*"としてあるので探しましょう。

"/var/backups/"は多くの重要な情報を保持しているので、これを別のパーティション上に置くのも良い考えです。

ひどく壊れた場合には、システムのバックアップをした後フレッシュに再インストールすることをお薦めします。たとえ"/var/"ディレクトリの中が完全に消去されても、"/usr/share/doc/"ディレクトリ中から新しいインストールのガイドとなる情報を回復できます。

  • 最低源の(デスクトップ)システムを再インストールします。
  • "/path/to/old/system/"に古いシステムを置く
# cd /path/to/old/system/usr/share/doc
# ls -1 >~/ls1.txt
# cd /usr/share/doc
# ls -1 >>~/ls1.txt
# cd
# sort ls1.txt | uniq | less

こうすると、インストールすべきパッケージ名が表示されます。("texmf"のようなパッケージ名以外が一部あるかもしれません。)

2.7. パッケージ管理のヒント

2.7.1. Debianパッケージの選択方法

パッケージの説明や"Tasks"の下のリストを使ってあなたが必要なパッケージをaptitudeで見つけることができます。

2つ以上の似たパッケージに出会いが"試行錯誤"の努力無しにどのパッケージをインストールするか迷った際には、常識を使って下さい。次に示す点は好ましいパッケージの良い指標と考えます。

  • 必須(essential): yes > no
  • コンポーネント(component): メイン(main) > contrib > non-free
  • 優先度(priorities): 必須(required) > 重要(important) > 標準(standard) > 任意(optional) > 特別(extra)
  • タスク(tasks): "デスクトップ環境"のようなタスクにリストされたパッケージ
  • 依存パッケージにより選ばれたパッケージ(例えば、pythonによるpython2.4)
  • popcon: higher in the vote and install number
  • changelog: メンテナによる定期的アップデート
  • BTS: RC bugが無いこと (criticalもgraveもseriousもいずれのバグも無い)
  • BTS: バグレポートに反応の良いメンテナ
  • BTS: 最近修正されたバグの数が多い
  • BTS: wishlist以外のバグが少ない

Debianは分散型の開発モデルのボランティアプロジェクトですので、そのアーカイブには目指すところや品質の異なる多くのパッケージがあります。これらをどうするかは自己判断をして下さい。

2.7.2. 混合したアーカイブソースからのパッケージ

[注意] 注意

安定版(stable)security updatesvolatile updatesのような公式にサポートされた特定の組み合わせ以外は、混合したアーカイブソースからのパッケージをインストールすることを、公式にはDebianディストリビューションとしてサポートしていません。

testingを追跡しながら、unstableにある特定の新規アップストリームバージョンのパッケージを1回だけ取り入れる操作例を次に示します。

  • "/etc/apt/sources.list"ファイルを変更し、単一の"unstable"エントリーのみにします。
  • "aptitude update"を実行します。
  • "aptitude install <パッケージ名>"の実行
  • testingのためのオリジナルの"/etc/apt/sources.list"ファイルを回復します。
  • "aptitude update"を実行します。

この様な手動のアプローチをすると"/etc/apt/preferences"ファイルを作ることもないし、またapt-pinningについて悩むこともありません。でもこれではとても面倒です。

[注意] 注意

混合したアーカイブソースを使うことをDebianが保証していないので、その場合にはパッケージ間の互換性は自分自身で確保しなければいけません。もしパッケージに互換性がないと、システムを壊すことになるかもしれません。この様な技術的要件を判断できる必要があります。ランダムな混合したアーカイブソースを使うことは全く任意の操作ですが、私としてはこの操作はお薦めできません。

異なるアーカイブからパッケージをインストールするための一般ルール:

非バイナリパッケージのインストールは比較的安全です。

  • 文書パッケージ: 特段の要件無し
  • インタープリタプログラムパッケージ: 互換性あるインタープリタ環境が必要

完全に静的にリンクされたバイナリパッケージのインストールは安全です。

バイナリパッケージ(非"Architecture: all")のインストールは、通常多くの障害があり、安全ではありません

  • ライブラリ("libc"等)のバージョン互換性
  • 関連ユーティリティプログラムのバージョン互換性
  • カーネルABI互換性
  • C++のABI互換性
[注意] 注意

壊れたパッケージを短期的に避ける場合以外では、公式にサポートされていないアーカイブからバイナリパッケージをインストールするのは一般的には賢明ではありません。たとえapt-pinning(「候補バージョンの調整」参照)を使った場合にもこれは当てはまります。chrootや類似のテクニック(「Chrootシステム」参照)使って、他のアーカイブからのプログラムを実行するよう検討するべきです。

2.7.3. 候補バージョンの調整

[警告] 警告

lennyaptitude(8)には、"/etc/apt/preferences"ファイルの扱いにバグ(Bug#514930参照)があります。

"/etc/apt/preferences"ファイル無しだと、APTシステムはバージョン文字列を用いて、最新バージョンを候補バージョンとします。これが通常状態でAPTシステムの最も推薦される使い方です。全ての公式にサポートされたアーカイブの組み合わせは、自動的にアップグレードするソースとすべきでないアーカイブはNotAutomaticとマークされていて適切な扱いを受けるので、"/etc/apt/preferences"ファイルを必要としません。

[ティップ] ティップ

バージョン文字列比較ルールは、例えば"dpkg --compare-versions ver1.1 gt ver1.1~1; echo $?"とすれば確認できます(dpkg(1)参照)。

パッケージを混合したアーカイブからのソース(「混合したアーカイブソースからのパッケージ」参照)から定常的にインストールする場合には、apt_preferences(5)に書かれたように適切な項目のある"/etc/apt/preferences"ファイルを作り候補バージョンに関するパッケージ選択ルールを操作することによってこういった複雑な操作を自動化できます。これをapt-pinningと呼びます。

[警告] 警告

初心者のユーザによるapt-pinningの利用は大トラブル発生を間違いなく起こします。本当に必要な時以外はapt-pinningの利用は避けなければいけません。

[注意] 注意

apt-pinningを利用する際には、Debianはパッケージの互換性を保証しないので、ユーザ自身がパッケージの互換性を確保しなければいけません。apt-pinningは全く任意の操作で、著者が使うようにと勧めているわけではありません。

[注意] 注意

アーカイブレベルのReleaseファイル(「アーカイブレベルの"Release"ファイル」参照)がapt_preferences(5)のルールに使われます。だから、apt-pinningはnormal Debian archivessecurity Debian archivesではスイート("suite")名を使って機能します。(これはUbuntuアーカイブとは異なります)。例えば"/etc/apt/preferences"ファイル中で、"Pin: release a=unstable"とはできますが、"Pin: release a=sid"とはできません。

[注意] 注意

非Debianアーカイブをapt-pinningの一部に使う場合には、それが提供されている対象の確認とその信頼性の確認をしましょう。例えば、UbuntuとDebianは混合して使うようにはなっていません。

[注意] 注意

"/etc/apt/preferences"ファイルを作成することなしでも、かなり複雑なシステム操作(「dpkgコマンドを使っての救済」「混合したアーカイブソースからのパッケージ」参照)がapt-pinningを使わずにできます。

単純化したapt-pinningテクニックの説明を次にします。

APTシステムは"/etc/apt/sources.list"ファイル中に規定された使えるパッケージソースから最高のPin-Priorityでアップグレードするパッケージを候補バージョンパッケージとして選択します。パッケージのPin-Priorityが1000より大きい場合には、このアップグレードするというバージョン制約が外れるのでダウングレードできるようになります(「緊急ダウングレード」参照)。

各パッケージのPin-Priority値は"/etc/apt/preferences"ファイル中の"Pin-Priority"項目にて規定されるか、そのデフォルト値が使われます。

表2.19 各パッケージソースタイプ毎のデフォルトPin-Priority値のリスト

デフォルトPin-Priority パッケージソースタイプ
990 ターゲットのリリースアーカイブ
500 通常アーカイブ
100 インストール済みアーカイブ
1 NotAutomaticアーカイブ

ターゲットのリリースアーカイブは次のようにして設定できます:

  • "/etc/apt/apt.conf"中にある、"APT::Default-Release "stable";"等の行によって。
  • "-t"オプションの引数によって、"apt-get install -t testing some-package"等によって。

NotAutomaticアーカイブは次のようにして設定できます:

複数アーカイブソースの<package>に関するPin-Priority値は"apt-cache policy <package>"の出力で表示されます:

  • "Package pin:"で始まる行は、<package>のみとの関連付けが"Package pin: 0.190"等と定義されている場合に、pinのパッケージバージョンを示します。
  • <package>とのみの関連付けが定義されていない場合には、"Package pin:"という行はありません。
  • <package>とのみの関連付けが定義されている場合のPin-Priority値は、全バージョン文字列の右側に"0.181 700"等としてリストされます。
  • <package>とのみの関連付けが定義されていない場合には、全バージョン文字列の右側に"0"が"0.181 0"等としてリストされます。
  • アーカイブのPin-Priority値("/etc/apt/preferences"ファイル中に"Package: *"として定義)はアーカイブへのパスの左側に、"200 http://backports.org etch-backports/main Packages"等としてリストされます。

testingを追跡しながら、unstableにある特定の新規アップストリームバージョンのパッケージが定常的にアップグレードされる、apt-pinningテクニックの例を次に示します。全ての必要なアーカイブを"/etc/apt/sources.list"ファイル中に次のようにリストします:

deb http://ftp.us.debian.org/debian/ testing main contrib non-free
deb http://ftp.us.debian.org/debian/ unstable main contrib non-free
deb http://security.debian.org/ testing/updates main contrib

"/etc/apt/preferences"を次のように設定する:

Package: *
Pin: release a=testing
Pin-Priority: 500

Package: *
Pin: release a=unstable
Pin-Priority: 200

"<package-name>"という名前のパッケージとその依存ファイルをunstableアーカイブからこの設定の下でインストールしたい場合、"-t"オプションを使ってターゲットリリースを切り替える(unstableのPin-Priorityが990になる)次のコマンドを実行します:

$ sudo apt-get install -t unstable <package-name>

この設定では、通常の"apt-get upgrade"や"apt-get dist-upgrade" (もしくはsqueezeの場合、"aptitude safe-upgrade"や"aptitude full-upgrade")の実行は、testingアーカイブからインストールされたパッケージは最新のtestingアーカイブを使ってアップグレードし、unstableアーカイブからインストールされたパッケージは最新のunstableアーカイブを使ってアップグレードします。

[注意] 注意

"/etc/apt/sources.list"ファイルから"testing"の項目を削除しないように注意しましょう。"testing"項目がその中にないと、APTシステムは最新のunstableアーカイブを使ってアップグレードしようとします。

[ティップ] ティップ

著者は上記操作のすぐ後に"/etc/apt/sources.list"ファイルを編集して"unstable"アーカイブ項目をコメントアウトします。こうすることで、最新のunstableアーカイブによってunstableからインストールされたパッケージをアップグレードしなくなりますが、"/etc/apt/sources.list"ファイル中に項目が多すぎてアップデートのプロセスが遅くなることをさけられます。

[ティップ] ティップ

もし"/etc/apt/preferences"ファイル中で"Pin-Priority: 200"の代わりに"Pin-Priority: 20"が用いられた場合は、"/etc/apt/sources.list"ファイルの中の"testing"項目が削除されようと、Pin-Priority値は100のインストール済みパッケージはunstableアーカイブによってアップグレードされる事はありません。

最初の"-t unstable"によるインストール無しに、unstableの特定パッケージを自動的に追跡したい場合、"/etc/apt/preferences"ファイルを作りそのトップにこれらパッケージを明示的に次のようにリストします:

Package: <package-1>
Pin: release a=unstable
Pin-Priority: 700

Package: <package-2>
Pin: release a=unstable
Pin-Priority: 700

...

以上で、各特定パッケージに関してPin-Priority値が設定されます。例えば最新のunstableバージョンのこの"Debianリファレンス"を英語版で追跡するためには、"/etc/apt/preferences"ファイルに次の項目を設定します:

Package: debian-reference-en
Pin: release a=unstable
Pin-Priority: 700

Package: debian-reference-common
Pin: release a=unstable
Pin-Priority: 700
[ティップ] ティップ

このapt-pinningテクニックはstableアーカイブを追跡している際にも有効です。著者の経験では、文書パッケージはunstableアーカイブからインストールしても今までいつも安全でした。

次にunstableを追跡しながらexperimentalにある特定の新規アップストリームバージョンのパッケージを取り込むapt-pinningテクニックの例を示します。すべての必要なアーカイブを"/etc/apt/sources.list"ファイルに次のようにリストします:

deb http://ftp.us.debian.org/debian/ unstable main contrib non-free
deb http://ftp.us.debian.org/debian/ experimental main contrib non-free
deb http://security.debian.org/ testing/updates main contrib

experimentalアーカイブのデフォルトのPin-Priority値は、NotAutomaticアーカイブ(「アーカイブレベルの"Release"ファイル」参照)なので、常に1(<<100)です。experimentalアーカイブにある特定パッケージを次回アップグレード時に自動的に追跡しようとしない限り、"/etc/apt/preferences"ファイル中でexperimentalアーカイブを使うためにPin-Priority値を明示的に設定する必要はありません。

2.7.4. VolatileとBackports.org

stableのためのアップグレードパッケージを提供する、debian-volatile projectbackports.orgアーカイブがあります。

[警告] 警告

lenny-backportsvolatile-sloppy等のNotAutomaticアーカイブの中にあるパッケージ全てを使ってはいけません。あなたの必要性に適合する選択されたパッケージだけを使いましょう。

[注意] 注意

backports.orgは、提供しているパッケージがDebian開発者によってサインされているとはいえ、非Debianアーカイブです。

[注意] 注意

アーカイブレベルのReleaseファイル(「アーカイブレベルの"Release"ファイル」参照)がapt_preferences(5)のルールで使われます。だからvolatile Debianアーカイブではapt-pinningは"コード"名を使って機能します。これは他のDebianアーカイブと異なります。例えばvolatile Debianアーカイブのための"/etc/apt/preferences"の中で、"Pin: release a=lenny"とできますが、"Pin: release a=stable"とはできません。

次にlennyvolatileを追跡しながらlenny-backportsにある特定の新規アップストリームバージョンのパッケージを取り込むapt-pinningテクニックの例を示します。すべての必要なアーカイブを"/etc/apt/sources.list"ファイルに次のようにリストします:

deb http://ftp.us.debian.org/debian/ lenny main contrib non-free
deb http://security.debian.org/ lenny/updates main contrib
deb http://volatile.debian.org/debian-volatile/ lenny/volatile main contrib non-free
deb http://volatile.debian.org/debian-volatile/ lenny/volatile-sloppy main contrib non-free
deb http://backports.org/debian/ lenny-backports main contrib non-free

backports.orgvolatile-sloppyアーカイブのデフォルトのPin-Priority値は、NotAutomaticアーカイブ(「アーカイブレベルの"Release"ファイル」参照)なので、常に1(<<100)です。experimentalアーカイブにある特定パッケージを次回アップグレード時に自動的に追跡しようとしない限り、"/etc/apt/preferences"ファイル中でbackports.orgvolatile-sloppyアーカイブを使うためにPin-Priority値を明示的に設定する必要はありません。

"<package-name>"という名前のパッケージをその依存関係ともどもlenny-backportsアーカイブからインストールしたい時には、"-t"オプションでターゲットリリースを切り替えながら次のコマンドを使います:

$ sudo apt-get install -t lenny-backports <package-name>

特定のパッケージをアップグレードしたいときには、"/etc/apt/preferences"ファイルを作成しその中に全てのパッケージを次のように明示的にリストしなければいけません:

Package: <package-1>
Pin: release o=Backports.org archive
Pin-Priority: 700

Package: <package-2>
Pin: release o=volatile.debian.org
Pin-Priority: 700

...

また、"/etc/apt/preferences"ファイルを次のようにしてもよい:

Package: *
Pin: release a=stable , o=Debian
Pin-Priority: 500

Package: *
Pin: release a=lenny, o=volatile.debian.org
Pin-Priority: 500

Package: *
Pin: release a=lenny-backports, o=Backports.org archive
Pin-Priority: 200

Package: *
Pin: release a=lenny-sloppy, o=volatile.debian.org
Pin-Priority: 200

"apt-get upgrade"と"apt-get dist-upgrade" (もしくは、squeezeでは"aptitude safe-upgrade"と"aptitude full-upgrade")の実行は、stableアーカイブからインストールされたパッケージを最新のstableアーカイブを使ってアップグレードし、他のアーカイブからインストールされたパッケージを最新の"/etc/apt/sources.list"ファイルに記載された全てのアーカイブの最新の対応するアーカイブを使ってアップグレードします。

2.7.5. パッケージの自動ダウンロードとアップグレード

aptパッケージには、パッケージの自動ダウンロードのサポートする専用のcronスクリプト"/etc/cron.daily/apt"が同梱されています。このスクリプトはunattended-upgradesパッケージをインストールすることで自動アップグレード実行の機能拡張をします。これらは、"/usr/share/doc/unattended-upgrades/README"に記述されているように、"/etc/apt/apt.conf.d/02backup"と"/etc/apt/apt.conf.d/50unattended-upgrades"の中のパラメータでカスタマイズできます。

unattended-upgradesパッケージは基本的にstableシステムのセキュリティアップグレードのためです。既存のstableシステムが、自動アップグレードで壊される危険性が、セキュリティアップグレードがすでに閉じたセキュリティホールからの侵入者によりシステムが壊わされる危険性より小さいなら、パラメータを設定して自動アップグレードをするのも一計です:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::Unattended-Upgrade "1";

unstableシステムを使っている場合には、自動アップグレードするとシステムはいつの日か確実に壊われるので、それはしたくないでしょう。そんなunstableの場合でも、事前にパッケージをダウンロードするようにパラメータを設定して、インタラクティブなアップグレードをするために時間を節約したいでしょう:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::Unattended-Upgrade "0";

2.7.6. APTのよるダウンロードバンド幅の制限

APTによるダウンロードのバンド幅を例えば800Kib/sec (=100kiB/sec)に制限したい場合には、APTのパラメータを次のように設定します:

APT::Acquire::http::Dl-Limit "800";

2.7.7. 緊急ダウングレード

[注意] 注意

Debianでは設計としてはダウングレードを正式にサポートしません。緊急の回復処置の一部としてのみ実行されるべきです。こういう状況であるにもかかわらず、多くの場合にうまく機能することがある知られています。重要なシステムでは回復処置の後に全ての重要データをバックアップし、最初から新しいシステムを再インストールしましょう。

壊れたシステムアップグレードからの回復するために、候補バージョンを操作して新しいアーカイブから古いアーカイブにダウングレードすることがうまくいくかもしれません(「候補バージョンの調整」参照)。これは、何度も"dpkg -i <broken-package>_<old-version>.deb"コマンドを実行する退屈な作業をしないでよくする方法です(「dpkgコマンドを使っての救済」参照)。

unstableからtestingを追跡するようにダウングレードするには、"/etc/apt/sources.list"ファイルを、次から:

deb http://ftp.us.debian.org/debian/ sid main contrib non-free

次へと変更します:

deb http://ftp.us.debian.org/debian/ squeeze main contrib

"/etc/apt/preferences"を次のように設定する:

Package: *
Pin: release a=testing
Pin-Priority: 1010

そして、"apt-get dist-upgrade"を実行して、システム全体にわたってパッケージのダウングレードを強制します。この特殊な"/etc/apt/preferences"ファイルはダウングレード実行後削除してください。

[ティップ] ティップ

依存関係の問題を最小限とすべく、できるだけ多くのパッケージを削除(removeで、完全削除purgeではありません!)しましょう。システムのダウングレードのためには手動でいくつかのパッケージを削除とインストールしなければいけないかも知れません。LinuxカーネルやブートローダやudevやPAMやAPTやネットワーク関係のパッケージやそれらの設定ファイルには特に注意が必要です。

2.7.8. 誰がパッケージをアップロードしたのか?

"/var/lib/dpkg/available"や"/usr/share/doc/package_name/changelog"の中にリストされたメンテナの名前は"誰がパッケージ化活動の背後にいるのか"に関していくばくかの情報を提供しますが、パッケージを実際にアップロードをした人がはっきりしません。devscriptsパッケージ中のwho-uploads(1)はDebianのソースパッケージを実際にアップロードした人を確定します。

2.7.9. equivsパッケージ

ソースからプログラムをコンパイルしてDebianパッケージを置換えたい際には、それを実際にローカルでDebian化してパッケージ(*.deb)して、私的アーカイブを使うのが好ましいです。

しかし、プログラムをソースからコンパイルして"/usr/local"にインストールすることを選んだ際には、パッケージ依存関係を満足させるための最後の手段としてequivsを使う必要があるかもしれません。

Package: equivs
Priority: extra
Section: admin
Description: Circumventing Debian package dependencies
 This is a dummy package which can be used to create Debian
 packages, which only contain dependency information.

2.7.10. 安定版システムへのパッケージ移植

stableシステムの部分アップグレードのためには、その環境内でソースパッケージを使ってパッケージをリビルドするのが好ましいです。こうすることでパッケージ依存関係による大掛かりなアップグレードをしないで済みます。まず、stableシステムの"/etc/apt/sources.list"に次の項目を追加します:

deb-src http://http.us.debian.org/debian unstable  main contrib non-free

次にコンパイルするのに必要なパッケージをインストールしソースパッケージをダウンロードします:

# apt-get update
# apt-get dist-upgrade
# apt-get install fakeroot devscripts build-essential
$ apt-get build-dep foo
$ apt-get source foo
$ cd foo*
  • 必要があればパッケージを調整します。
$ dch -i
  • パッケージバージョンを、"+bp1"を後ろに付けるなどして、先に進めます。
$ debuild
$ cd ..
# debi foo*.changes

2.7.11. APTのためのプロキシサーバー

Debianアーカイブの特定サブセクション全てをミラーするとディスクスペースとネットワークのバンド幅の大いなる無駄遣いですので、LAN上に多くのシステムを管理している際にはAPTのためのローカルのプロキシサーバーを設置することを考えるのは良いことです。APTは、apt.conf(5) とか"/usr/share/doc/apt/examples/configure-index.gz"に説明されたようにして、汎用のsquidのような ウエッブ(http)プロキシサーバー(「Other network application servers」参照)を使うように設定できます。"$http_proxy"環境変数による設定は、"/etc/apt/apt.conf"ファイル中の設定より優先します。

Debianアーカイブ専用のプロキシツールがあります。実際に使う前にBTSをチェック下さい。

表2.20 Debianアーカイブ専用のプロキシツールのリスト

パッケージ popcon サイズ 説明
approx V:0.2, I:0.3 3860 Debianアーカイブファイルのキャッシュプロキシサーバー(コンパイルされたOCamlプログラム)
apt-proxy V:0.4, I:0.5 428 Debianアーカイブプロキシと部分ミラー作成機(Pythonプログラム)
apt-cacher V:0.3, I:0.5 244 Debianパッケージとソースファイルのキャッシュプロキシ(Perlプログラム)
apt-cacher-ng V:0.17, I:0.2 708 ソフトウエアパッケージの頒布ためのキャッシュプロキシ(コンパイルされたC++プログラム)
debtorrent V:0.14, I:0.2 1173 Debianパッケージのためのbittorrentプロキシ(Pythonプログラム)

[注意] 注意

Debianがそのアーカイブ構造を再編した際に、このような専用のプロキシツールはパッケージメンテナによるコードの修正が必要で、一定期間使えなくなることがあります。一方、汎用のウエッブ(http)プロキシは比較的堅牢ですしそのような変化に合わすのも簡単です。

2.7.12. 小さな公開パッケージアーカイブ

近代的なセキュアAPTシステム(「トップレベルの"Release"ファイルと信憑性」参照)と互換性のある小規模のパブリックアーカイブを作る例を次に示します。まず、いくつかの仮定をします:

  • アカウント名: "foo"
  • ホスト名: "www.example.com"
  • 必要なパッケージ: apt-utilsgnupg等のパッケージ。
  • URL: "http://www.example.com/~foo/"は"/home/foo/public_html/index.html"を表示します。
  • パッケージのアーキテクチャ: "amd64"

あなたのサーバーシステム上でのAPTアーカイブの1回だけのセットアップ:

  • サーバーシステム上のFooのアーカイブキーを作成:
$ ssh foo@www.example.com
$ gpg --gen-key
...
$ gpg -K
...
sec   1024D/3A3CB5A6 2008-08-14
uid                  Foo (ARCHIVE KEY) <foo@www.example.com>
ssb   2048g/6856F4A7 2008-08-14
$ gpg --export -a 3A3CB5A6 >foo.public.key
  • Fooのアーカイブキーは"3A3CB5A6"
  • "foo.public.key"ファイルを公開します。
  • "Origin: Foo"というアーカイブツリーを作成します:
$ umask 022
$ mkdir -p ~/public_html/debian/pool/main
$ mkdir -p ~/public_html/debian/dists/unstable/main/binary-amd64
$ mkdir -p ~/public_html/debian/dists/unstable/main/source
$ cd ~/public_html/debian
$ cat > dists/unstable/main/binary-amd64/Release << EOF
Archive: unstable
Version: 4.0
Component: main
Origin: Foo
Label: Foo
Architecture: amd64
EOF
$ cat > dists/unstable/main/source/Release << EOF
Archive: unstable
Version: 4.0
Component: main
Origin: Foo
Label: Foo
Architecture: source
EOF
$ cat >aptftp.conf <<EOF
APT::FTPArchive::Release {
  Origin "Foo";
  Label "Foo";
  Suite "unstable";
  Codename "sid";
  Architectures "amd64";
  Components "main";
  Description "Public archive for Foo";
};
EOF
$ cat >aptgenerate.conf <<EOF
Dir::ArchiveDir ".";
Dir::CacheDir ".";
TreeDefault::Directory "pool/";
TreeDefault::SrcDirectory "pool/";
Default::Packages::Extensions ".deb";
Default::Packages::Compress ". gzip bzip2";
Default::Sources::Compress "gzip bzip2";
Default::Contents::Compress "gzip bzip2";

BinDirectory "dists/unstable/main/binary-amd64" {
  Packages "dists/unstable/main/binary-amd64/Packages";
  Contents "dists/unstable/Contents-amd64";
  SrcPackages "dists/unstable/main/source/Sources";
};

Tree "dists/unstable" {
  Sections "main";
  Architectures "amd64 source";
};
EOF

あなたのサーバーシステム上のAPTアーカイブ内容の繰り返しアップデート:

  • 次に示す内容の"~/.dupload.conf"を設定したクライアントで"dupload -t foo changes_file"を実行することで、全てのパッケージファイルを"~foo/public_html/debian/pool/main/"に置きます:
$cfg{'foo'} = {
  fqdn => "www.example.com",
  method => "scpb",
  incoming => "/home/foo/public_html/debian/pool/main",
  # The dinstall on ftp-master sends emails itself
  dinstall_runs => 1,
};

$cfg{'foo'}{postupload}{'changes'} = "
  echo 'cd public_html/debian ;
  apt-ftparchive generate -c=aptftp.conf aptgenerate.conf;
  apt-ftparchive release -c=aptftp.conf dists/unstable >dists/unstable/Release ;
  rm -f dists/unstable/Release.gpg ;
  gpg -u 3A3CB5A6 -bao dists/unstable/Release.gpg dists/unstable/Release'|
  ssh foo@www.example.com  2>/dev/null ;
  echo 'Package archive created!'";

dupload(1)が起動するpostuploadフックスクリプトがアップロード毎に更新されたアーカイブファイルを作成します。

この小規模のパブリックアーカイブをクライアントシステムのapt行に追加できます:

$ sudo bash
# echo "deb http://www.example.com/~foo/debian/ unstable main" \
   >> /etc/apt/sources.list
# apt-key add foo.public.key
[ティップ] ティップ

もしローカルファイルシステム上にアーカイブがある場合には、上記の代わりに"deb file:///home/foo/debian/ …"が使えます。

2.7.13. システム設定の記録/コピー

パッケージとdebconfの選択状態のローカルコピーを作るには:

# dpkg --get-selections '*' > selection.dpkg
# debconf-get-selections    > selection.debconf

ここで、"*"は"selection.dpkg"が"purge"に関するパッケージ項目も含めるようにします。

これら2ファイルを他のコンピュータに移動し、次のようにしてインストールします:

# dselect update
# debconf-set-selections < myselection.debconf
# dpkg --set-selections  < myselection.dpkg
# apt-get -u dselect-upgrade    # or dselect install

実質的に同じ設定でクラスターとなった多くのサーバーを管理することをお考えの場合には、専用パッケージであるfai等を使って全システムを管理することを考えましょう。

2.7.14. 外来のバイナリパッケージを変換やインストールする

alien(1)を使うと、Red HatのrpmやStampedeのslpやSlackwareのtgzやSolarisのpkgファイルフォーマットをDebianのdebパッケージに変換できます。あなたのシステムにインストールしたパッケージに替えて他のLinuxディストリビューション由来のパッケージを使いたい際には、alienを使って変換しインストールします。alienはLSBパッケージをサポートします。

[警告] 警告

alien(1)はsysvinitlibc6libpam-modules等の必須のシステムパッケージを置き換えるために使うべきではありません。実質的にはalien(1)は、LSB準拠か静的にリンクされたnon-freeのバイナリのみで提供されるパッケージにのみ使われるべきです。フリーソフトの場合は、ソースパッケージを使い本物のDebianパッケージを作るべきです。

2.7.15. dpkgを使わずにパッケージを開梱

現行の"*.deb"パッケージの内容は、どんなUnix的環境でも標準のar(1)とtar(1)を使っうことで、dpkg(1)を使うこと無く開梱できます。

# ar x /path/to/dpkg_<version>_<arch>.deb
# ls
total 24
-rw-r--r-- 1 bozo bozo  1320 2007-05-07 00:11 control.tar.gz
-rw-r--r-- 1 bozo bozo 12837 2007-05-07 00:11 data.tar.gz
-rw-r--r-- 1 bozo bozo     4 2007-05-07 00:11 debian-binary
# mkdir control
# mkdir data
# tar xvzf control.tar.gz -C control
# tar xvzf data.tar.gz -C data

パッケージの内容はmcコマンドを使っても閲覧できます。

2.7.16. パッケージ管理の追加参考文書

以下を参照:

  • aptitude(8)とdpkg(1)とtasksel(8)とapt-get(8)とapt-config(8)とapt-key(8)とsources.list(5)とapt.conf(5)とapt_preferences(5);
  • "/usr/share/doc/apt-doc/guide.html/index.html"と"/usr/share/doc/apt-doc/offline.html/index.html" from the apt-doc package;
  • aptitude-doc-enパッケージに入っている、"/usr/share/doc/aptitude/html/en/index.html"。

正規の詳細なDebianアーカイブに関する2次情報は次にあります:

Debianユーザ向けのDebianパッケージ作成の入門書は次です: