第2章 Debian パッケージ管理

# 第2章 Debian パッケージ管理

| 注記
本章は最新安定版リリースがコード名: `trixie` と言う前提で書かれています。 APT システムのデーターソースは本文書中では集合的にソースリストと表記されます。これは、"`/etc/apt/sources.list`" ファイルか、 "`/etc/apt/sources.list.d/*.list`" ファイルか、 "`/etc/apt/sources.list.d/*.sources`" ファイルの中の何処かに定義されます。

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

### 2.1.1. Debian パッケージ管理システム

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

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

これら全てのリソースを利用できる現行の Debian パッケージ管理システムは Advanced Packaging Tool (APT) です。

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

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

- パッケージのインストールや削除や dist-upgrade を含む全ての対話的コマンドライン操作を提供する、`apt`(8)。

- スクリプトから Debian のパッケージ管理をするためによぶ、`apt-get`(8)。(古い Debian システム等で)`apt` が使えない際の控えのオプション。

- インストールされたパッケージを管理したり、使用可能なパッケージを探索するためのインタラクティブなテキストインターフェースを提供する、`aptitude`(8)

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

パッケージ | ポプコン | サイズ | 説明
--- | --- | --- | ---
`dpkg` | V:889, I:999 | 6385 | Debian のための低水準パッケージ管理システム（ファイルベース）
`apt` | V:875, I:999 | 4670 | CLI でパッケージを管理する APT フロントエンド: `apt`/`apt-get`/`apt-cache`
`aptitude` | V:36, I:181 | 4624 | フルスクリーンコンソール中でインタラクティブにパッケージを管理する APT フロントエンド: `aptitude`(8)
`tasksel` | V:36, I:983 | 349 | 選択されたタスクをインストールする APT フロントエンド: `tasksel`(8)
`unattended-upgrades` | V:124, I:184 | 317 | セキュリティー更新の自動インストールを可能にする APT の拡張パッケージ
`gnome-software` | V:165, I:274 | 4476 | GNOME用のソフトウェアーセンター (GUI APT フロントエンド)
`synaptic` | V:37, I:304 | 7788 | グラフィカルなパッケージマネージャー (GTK APT フロントエンド)
`apt-utils` | V:399, I:997 | 1151 | APT ユーティリティープログラム: `apt-extracttemplates`(1) と `apt-ftparchive`(1) と `apt-sortpkgs`(1)
`apt-listchanges` | V:382, I:888 | 547 | パッケージ変更履歴の通知ツール
`apt-listbugs` | V:5, I:7 | 514 | APT による各インストール前にクリチカルバグをリストする
`apt-file` | V:15, I:58 | 89 | APT パッケージ探索ユーティリティー -- コマンドラインインターフェース
`apt-rdepends` | V:0, I:4 | 39 | パッケージの依存関係を再帰的にリスト

### 2.1.2. パッケージ設定

Debian システム上でのパッケージ設定の要点を次に記します。

- 現代的デスクトップ環境では、パッケージ設定変更やパッケージアップグレード後にシステムをリブートすることが、システムの適正稼働に好ましい。

- システム管理者による手動の設定は尊重されます。言い換えれば、パッケージ設定システムは利便性のために勝手な設定をしません。

- 各パッケージは、`debconf`(7) と呼ばれる標準化されたユーザーインターフェースを使用するパッケージの初期インストールプロセス支援のためのパッケージ毎の設定スクリプトが同梱されています。

- Debian の開発者はパッケージの設定スクリプトによりユーザーのアップグレードが滞りなく進むように最大限の努力を行います。

- システム管理者にはパッケージされたソフトウェアーの全機能が利用可能です。ただしセキュリティーリスクのある機能はデフォールトのインストール状態では無効にされています。

- セキュリティーリスクのあるサービスを手動でアクティベートした場合は、リスクの封じ込めはあなたの責任です。

- システム管理者は難解奇異な設定を手動で有効にはできます。ただこんなことをすればポピュラーな一般の補助プログラムと干渉してしまうかもしれません。

### 2.1.3. 基本的な注意事項

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

初心者の Debian システム管理者は Debian の安定版 `stable` リリースをセキュリティー更新を適用しながら使うべきです。Debian システムを非常によく理解するまでは、以下の予防策を守るべきです。

- ソースリスト中にテスト版 `testing` とか不安定版 `unstable` とかを含めない。

- ソースリスト中に標準の 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.4. 永遠のアップグレード人生

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

私が上記のような警告をしても、多くの本文書の読者は、テスト版 `testing` や不安定版 `unstable` スイーツを使いたいと考えるのは分かっています。

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

本リストは自己管理された デスクトップ環境を対象とします。

- Debian continuous integration と source only upload practices と library transition tracking 等の Debian アーカイブの QA インフラで自動管理された実質的にローリングリリースだから、`testing` スイートを使いましょう。`testing` スイートのパッケージは全ての最新機能を提供するのに十分頻繁に更新されます。

- テスト版 `testing` スイーツに該当するコードネーム (`trixie` が 安定版 `stable` であるリリース期間の場合"`forky`") をソースリスト中に設定します。

- メジャースイートリリースの約一ヶ月後に自分自身で状況を確認した後でソースリストの中のこのコードネームを新しいコードネームに手動で更新します。Debian user と developer のメーリングリストもこれに関する良好な情報源です。

非安定版 `unstable` スイーツを使うことは推奨できません。非安定版 `unstable` スイーツは開発者として パッケージのデバグには好適ですが、普通のデスクトップ使用ではあなたを不要なリスクに晒してしまいます。Debian システムの非安定版 `unstable` スイーツは、ほぼいつも非常に安定に見えるとはいえ、過去パッケージ上の問題をいくつか経験して来てるし、その一部は簡単には解決できないものでした。

Debian パッケージのバグからの早急かつ簡単な復元を確実にするいくつかの予防策のアイデアです。

- Debian システムの安定版 `stable` スイーツを別のパーティションにインストールし、システムをヂュアルブータブル化

- レスキューブートのためのインストール用 CD を手元に確保

- `apt-listbugs` をインストールしてアップグレードの前に Debian バグトラッキングシステム (BTS) をチェックを考慮

- 問題回避するのに十分なだけのパッケージシステムの基盤を学習

| 注意
これらの予防策の何れもできないなら、テスト版 `testing` や不安定版 `unstable` スイーツを使うのには、きっとあなたは準備不足です。

### 2.1.5. Debian アーカイブの基本

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

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

システムユーザーから見ると、Debian アーカイブは APT システムを用いてアクセスされます。

APT システムは、そのデーターソースをソースリストとして指定し、それは `sources.list`(5) に説明されています。

典型的 HTTP アクセスを使う `trixie` システムに関する一行スタイルのソースリストは以下です:

    deb http://deb.debian.org/debian/ trixie main non-free-firmware contrib non-free
    deb-src http://deb.debian.org/debian/ trixie main non-free-firmware contrib non-free

    deb http://security.debian.org/debian-security trixie-security main non-free-firmware contrib non-free
    deb-src http://security.debian.org/debian-security trixie-security main non-free-firmware contrib non-free

これに代わりうる、deb822スタイルの等価なソースリストは以下です。

    Types: deb deb-src
    URIs: http://deb.debian.org/debian/
    Suites: trixie
    Components: main non-free-firmware contrib non-free

    Types: deb deb-src
    URIs: http://security.debian.org/debian-security/
    Suites: trixie-security
    Components: main non-free-firmware contrib non-free

ソースリストの要点は以下です。

- 一行スタイル様式

  - その定義ファイルは "`/etc/apt/sources.list`" ファイルと "`/etc/apt/sources.list.d/*.list`" ファイルです。

  - 各行は APT システムのデーターソースを定義します。

  - "`deb`" 行がバイナリーパッケージのための定義です。

  - "`deb-src`" 行がソースパッケージのための定義です。

  - 一番目の引数は、Debian アーカイブの root URL です。

  - 二番目の引数は、スイーツ名かコード名のどちらかで与えられるディストリビューション名です。

  - 三番目以下の引数は、Debian アーカイブの中の有効なアーカイブのエリア名のリストです。

- deb822スタイル様式

  - その定義ファイルは "`/etc/apt/sources.list.d/*.sources`" ファイルです。

  - 空行で分離されている複数行の各ブロックは APT システムのデーターソースを定義します。

  - "`Types:`" スタンザは"`deb`" や "`deb-src`" といったタイプのリストを定義します。

  - The "`URIs:`" スタンザは Debian アーカイブのルート URI のリストを定義します。

  - "`Suites:`" スタンザは スイート名かコードネームのいずれかを用いてディストリビューションのリストを定義します。

  - "`Components:`" スタンザは Debian アーカイブの中の有効なアーカイブのエリア名のリストを定義します。

ソース関連のメタデーターにアクセスしない `aptitude` のためだけなら "`deb-src`" 行は安全に省略することができます。こうするとアーカイブのメタデーターの更新速度が向上します。

URL は "`https://`", "`http://`", "`ftp://`", "`file://`", … のいずれも可能です。

"`#`" で始まる行はコメントで無視されます。

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

| ヒント
もし上記の例で "`trixie`" ではなく "`sid`" が使われる場合には、"`deb: http://security.debian.org/ ...`" 行やそのdeb822相当の内容は ソースリスト には不要です。これは"`sid`" (不安定版 `unstable`) には、セキュリティー更新のアーカイブが存在しないからです。

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

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

アーカイブの URL | スイート名 | コードネーム | レポジトリーの用途
--- | --- | --- | ---
http://deb.debian.org/debian/ | `stable` | `trixie` | 徹底的な確認後の擬似静的 `stable` (安定版)リリース
http://deb.debian.org/debian/ | `testing` | `forky` | 適度の確認と短い待機後の動的 `testing` (テスト版)リリース
http://deb.debian.org/debian/ | `unstable` | `sid` | 最小限の確認と無待機後の動的 `unstable` (不安定版)リリース
http://deb.debian.org/debian/ | `experimental` | N/A | 開発者によるプリリリース実験 (任意、開発者専用)
http://deb.debian.org/debian/ | `stable-proposed-updates` | `trixie-proposed-updates` | 次期 `stable` (安定版)ポイントリリース用の更新 (任意)
http://deb.debian.org/debian/ | `stable-updates` | `trixie-updates` | タイムゾーンデーターのような緊急更新が必要な `stable-proposed-updates` スイートの部分集合 (任意)
http://deb.debian.org/debian/ | `stable-backports` | `trixie-backports` | 主に `testing` リリースから再コンパイルされたパッケージのランダムな集合
http://security.debian.org/debian-security/ | `stable-security` | `trixie-security` | `stable` リリース用のセキュリティーアップデート (重要)
http://security.debian.org/debian-security/ | `testing-security` | `forky-security` | セキュリティーチームによるサポートは無く利用されてません

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

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

| ヒント
`stable` スイーツの Debian システムは、上記の例のようにソースリスト中にセキュリティー更新を有効とする "`http://security.debian.org/`" を含む内容を織り込むことが望ましいです。

| 注記
`stable` アーカイブのセキュリティーバグは Debian のセキュリティーチームにより修正されます。本活動は非常に厳格で信頼できるものです。`testing` アーカイブのセキュリティーバグは Debian の testing セキュリティーチームにより修正されます。諸所の 事情で、本活動は `stable` ほどは厳格ではなく、修正された `unstable` パッケージの`testing` アーカイブへの移行を待つ必要があるかもしれません。`unstable` アーカイブのセキュリティーバグは個別のメンテナにより修正されます。活発にメンテされている `unstable` パッケージはアップストリームのセキュリティー修正を使うことで通常比較的良い状態です。Debian がセキュリティーバグへ如何に対応するかに関しては Debian security FAQ を参照下さい。

表2.3 Debian アーカイブエリアのリスト

エリア | パッケージ数 | パッケージ構成要素のクライテリア
--- | --- | ---
`main` | 72513 | DFSG に完全準拠し、`non-free` のパッケージに非依存 (main = 主要)
`non-free-firmware` | 64 | DFSG 非コンプライアント、合理的なシステムインステレーション経験のために必要なファームウエアー
`contrib` | 377 | DFSG に完全準拠だが、`non-free` のパッケージに依存有り (contrib = 寄与)
`non-free` | 1033 | DFSG に非準拠で `non-free-firmware` に含まれない

ここで、上記にあるパッケージ数は amd64 アーキテクチャーに関する数字です。`main` エリアのアーカイブのみが Debian システムです(「Debian は 100% フリーソフトウェアーです」を参照下さい)。

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

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

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

タイミング | スイーツ = 安定版 `stable` | スイーツ = テスト版 `testing` | スイーツ = 不安定版 `unstable`
--- | --- | --- | ---
`trixie` リリース後 | コード名 = `trixie` | コード名 = `forky` | コード名 = `sid`
`forky` リリース後 | コード名 = `forky` | コード名 = `duke` | コード名 = `sid`

コード名の歴史は、Debian FAQ: 6.2.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` アーカイブへパッケージ集合が移動される前に、アーカイブ管理スクリプトはパッケージの成熟度 (約2-10日経過) と RC バグレポート状況を確認するばかりでなく、テスト版 `testing` アーカイブの最新パッケージ集合との互換となるよう努めます。このプロセスがあるので、テスト版 `testing` アーカイブは非常に新しくかつ使いやすいのです。

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

不安定版 `unstable` もテスト版 `testing` アーカイブもともにいくつかの要因で一時的に細かな問題発生があるかもしれません。

- ブロークンなパッケージのアーカイブへのアップロード (主に `unstable` にて)

- 新規パッケージをアーカイブに受け入れる際の遅延 (主に `unstable` にて)

- アーカイブの同期のタイミング問題 (`testing` と `unstable` の両方にて)。

- パッケージの除去などのアーカイブへの手動の介入 (どちらかといえば `testing` にて)、等。

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

| 注意

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

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

アーカイブの定義は、Debian ポリシーマニュアルを参照下さい。

- "セクション"

- "優先度 (priorities)"

- "ベースシステム"

- "必須パッケージ"

### 2.1.6. Debian は 100% フリーソフトウェアーです

Debian は以下の理由で 100% フリーソフトウェアーです:

- Debian はユーザーの自由を尊重すべくデフォルトではフリーソフトウェアのみをインストールします。

- Debian は `main` 中にはフリーソフトウェアーのみを提供します。

- Debian は `main` からのフリーソフトウェアーのみを実行することを推奨します。

- `main` 中のいかなるパッケージも `non-free` や `non-free-firmware` や `contrib` 中のいずれのパッケージに依存しないし、これらを推薦することもありません。

一部の人は以下の2つの事実が矛盾するのでは無いかとの疑問を持ちます。

- 「Debian は 100% フリーソフトウェアーであり続けます」。Debian 社会契約の第一項)

- Debian サーバーは `non-free-firmware` や `non-free` や `contrib` パッケージをホストします。

これらは以下の理由で矛盾しません。

- Debian システムは 100% フリーソフトウェアーでそのパッケージは Debian サーバーの `main` エリア中にホストされます。

- Debian システム外のパッケージは Debian サーバーの `non-free` と `non-free-firmware` と `contrib` エリア中にホストされます。

これらは Debian 社会契約の第4項と第5項中に正確に説明されています:

- 私たちはユーザーとフリーソフトウェアーを大切にします

  - 私たちはユーザーとフリーソフトウェアーコミュニティーからの要求に従います。 彼らの関心を最優先に考えます。 私たちはさまざまな状況におけるコンピューター利用環境の運用に関して、 ユーザーの必要を満たすように行動します。私たちは Debian システム上での利用を目的としたフリーではない著作物に敵対することはありません。 またそのような著作物を作成または利用する人々に対して、料金を徴収することはありません。 私たちは、Debian システムとその他の著作物の両方を含むディストリビューションを、 第三者が作成することも認めています。その際、私たちは料金を徴収しません。 私たちはこれらの目標を増進させるために、 これらのシステムの使用を妨げるような法的な制約のない、 高品質な素材を統合したシステムを提供します。

- 私たちのフリーソフトウェアー基準に合致しない著作物について

  - 私たちは、Debian フリーソフトウェアー ガイドラインに適合していない著作物を 使わなければならないユーザーがいることを認めています。 このような著作物のために、私たちはアーカイブに「`non-free`」と「`non-free-firmware`」と「`contrib`」という領域を作りました。 これらの領域にあるパッケージは、Debian 上で使用できるよう設定されていますが、 Debian システムの一部ではありません。 私たちは、CD 製造業者がこれらの領域にあるパッケージを彼らの CD に収録して配布できるかどうか判断する際に、 それぞれのパッケージのライセンスを読んで決めるよう奨めています。 このように、フリーではない著作物は Debian の一部ではありませんが、 その使用をサポートし、フリーではないパッケージのための (バグ追跡システムやメーリングリストのような) インフラストラクチャーを用意しています。

| 注記
Debian 社会契約 1.2 の第 5 項の実際の文言は上記と少々違います。この編集上導入したズレは、社会契約の本質的内容を変えること無く本ユーザー文書の自己整合性を確保するために意識的に作られたズレです。

ユーザーは `non-free` や `non-free-firmware` や `contrib` エリア中のパッケージを使用するリスクを認識すべきです。

- そのようなソフトウェアーパッケージに関する自由の欠如

- そのようなソフトウェアーパッケージに関するDebianからのサポートの欠如 (Debian はソフトウェアーのソースコードに適切なアクセスなしにはソフトウェアーをサポートできません。)

- あなたの 100% フリーソフトウェアーの Debain システムへの汚染

Debian フリーソフトウェアー ガイドラインは Debian のフリーソフトウェアー基準です。Debian は「ソフトウェアー」に関して、パッケージ中の文書、ファームウエアー、ロゴ、アート作品を含む最も広義の解釈をします。このことにより Debian のフリーソフトウェアー基準は非常に厳格なものとなります。

典型的な `non-free` や `non-free-firmware` や `contrib` パッケージは以下のタイプの自由に頒布できるパッケージを含んでいます。

- GCC や Make 等の変更不可部分付きの GNU フリー文書利用許諾契約書 に基づく文書パッケージ。 (主に `non-free/doc` セクション中にある)

- 「ハードウエアードライバーとファームウエアー」 に列記された中で `non-free-firmware` とあるソースコード無しのバイナリーデーターを含むファームウエアーパッケージ。 (主に `non-free-firmware/kernel` セクション中にある)

- 商用使用やコンテント変更に関する制約のあるゲームやフォントのパッケージ。

`non-free` と `non-free-firmware` と `contrib` パッケージの数は `main` パッケージの数の 2% 以下ということを承知下さい。`non-free` や `non-free-firmware` や `contrib` エリアへのアクセスを有効にしてもパッケージソースは不明瞭になりません。`aptitude`(8) をインタラクティブでフルスクリーンに使用すると、どのエリアからどのパッケージをインストールするのかを完全に可視化しコントロールできるので、あなたのシステムをあなたの意向通りの自由の程度に合わせて維持できます。

### 2.1.7. パッケージ依存関係

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

- "Depends"

  - これは絶対依存を宣言し、このフィールドにリストされた全てのパッケージは同時または事前にインストールされていなければいけません。

- "Pre-Depends"

  - これは、リストされたパッケージが事前にインストールを完了している必要がある以外は、Depends と同様です。

- "Recommends"

  - これは強いが絶対でない依存を宣言します。多くのユーザーはこのフィールドにリストされたパッケージ全てがインストールされていなければ、当該パッケージを望まないでしょう。

- "Suggests"

  - これは弱い依存を宣言します。このパッケージの多くのユーザーはこのフィールドにリストされたパッケージをインストールすればメリットを享受できるとは言え、それら抜きでも十分な機能が得られます。

- "Enhances"

  - これは Suggests 同様の弱い依存を宣言しますが、依存作用の方向が逆です。

- "Breaks"

  - これは通常バージョン制約付きでパッケージのインコンパチビリティーを宣言します。一般的にこのフィールドにリストされた全てのパッケージをアップグレードすることで解決します。

- "Conflicts"

  - これは絶対的排他関係を宣言します。このフィールドにリストされた全てのパッケージを除去しない限り当該パッケージをインストールできません。

- "Replaces"

  - 当該パッケージによりインストールされるファイルがこのフィールドにリストされたパッケージのファイルを置き換える際にこれを宣言します。

- "Provides"

  - 当該パッケージがこのフィールドにリストされたパッケージのファイルと機能の全てを提供する際にこれを宣言します。

| 注記
合理的な設定として "Provides" と "Conflicts" と "Replaces" とを単一バーチャルパッケージに対し同時宣言することが合理的な設定であることを承知下さい。こうするといかなる時にも当該バーチャルパッケージを提供する実パッケージのうち確実に一つだけがインストールされます。

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

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

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

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

  1. アーカイブメタデーターをリモートアーカイブから取得

  2. APT が使えるようローカルメタデーターの再構築と更新

- 更新 ("`apt upgrade`" と "`apt full-upgrade`"か、"`aptitude safe-upgrade`" と "`aptitude full-upgrade`" か、"`apt-get upgrade`" と "`apt-get dist-upgrade`"):

  1. 全てのインストール済みパッケージに関して、通常最新の利用可能なバージョンを選択します (例外については「apt-pinning で候補バージョンを調整」を参照下さい)

  2. パッケージ依存関係解決の実行

  3. もし候補バージョンがインストール済みバージョンと異なる際には、選ばれたバイナリーパッケージをリモートアーカイブから取得

  4. 取得バイナリーパッケージの開梱

  5. preinst スクリプトの実行

  6. バイナリーファイルのインストール

  7. postinst スクリプトの実行

- インストール ("`apt install ...`" か "`aptitude install ...`" か "`apt-get install ...`"):

  1. コマンドラインにリストされたパッケージの選択

  2. パッケージ依存関係解決の実行

  3. 選ばれたバイナリーパッケージをリモートアーカイブから取得

  4. 取得バイナリーパッケージの開梱

  5. preinst スクリプトの実行

  6. バイナリーファイルのインストール

  7. postinst スクリプトの実行

- 削除 ("`apt remove ...`" か "`aptitude remove ...`" か "`apt-get remove ...`"):

  1. コマンドラインにリストされたパッケージの選択

  2. パッケージ依存関係解決の実行

  3. prerm スクリプトの実行

  4. 設定ファイル以外のインストール済みファイルの削除

  5. postrm スクリプトの実行

- 完全削除 ("`apt purge ...`" か "`aptitude purge ...`" か "`apt-get purge ...`"):

  1. コマンドラインにリストされたパッケージの選択

  2. パッケージ依存関係解決の実行

  3. prerm スクリプトの実行

  4. 設定ファイルを含めたインストール済みファイルの削除

  5. postrm スクリプトの実行

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

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

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

    $ cd package_name
    $ pager README.Debian
    $ mc

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

特定パッケージに関する問題に出会った際には、Debian バグトラッキングシステム (BTS) サイトを必ず確認します。

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

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

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

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

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

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

- 必須 (essential): yes > no

- エリア (area): メイン (main) > contrib > non-free

- 優先度 (priority): 必須 (required) > 重要 (important) > 標準 (standard) > 任意 (optional) > 特別 (extra)

- タスク (tasks): "デスクトップ環境" のようなタスクにリストされたパッケージ

- 依存パッケージにより選ばれたパッケージ (例えば、`gcc` による `gcc-10`)

- ポプコン: 投票やインストールの数が多い

- changelog: メンテナによる定期的更新

- BTS: RC bug が無いこと (critical も grave も serious もいずれのバグも無い)

- BTS: バグレポートに反応の良いメンテナ

- BTS: 最近修正されたバグの数が多い

- BTS: wishlist 以外のバグが少ない

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

### 2.1.11. 矛盾した要求への対処法

どのスイートの Debian システムを使うと決めようと、そのスイートで利用可能となっていないプログラムのバージョンをなんとか実行したいかもしれません。そのようなプログラムのバイナリーパッケージが他の Debian スイートとか他の非 Debian リソースで見つかるかもしれませんが、あなたの現行の Debian システムはそれらの要求条件と相容れないかもしれません。

そのような不同期のバイナリーパッケージをインストールする「apt-pinning で候補バージョンを調整」に記載されたような apt-pinning テクニック等を用いてパッケージ管理システムを微調整することができるとはいえ、そのような微調整はそれらのプログラムやあなたのシステムを壊すかもしれないので、そのような微調整のアプローチには限定的なユースケースしかありません。

そのような非同期のパッケージを強引にインストールする前に、あなたの現行の Debian システムとコンパチブルな、全ての利用可能な安全な技術的解決策を探索すべきです。

- 対応するサンドボックス化したアップストリームのバイナリーパッケージをインストール(「サンドボックス」を参照下さい)。

  - LibreOffice や GNOME アプリケーション等の多くの主に GUI プログラムは、Flatpak や Snap や AppImage パッケージが利用可能です。

- chroot か類似の環境を作り、その中でそのようなプログラムを実行 (「仮想化システム」を参照下さい)。

  - CLI コマンドは、それとコンパチブルな chroot 下で簡単に実行できます(「Chroot システム」を参照下さい)。

  - 複数のフルのデスクトップ環境をリブートすること無く簡単に試せます(「複数のデスクトップシステム」を参照下さい)。

- あなたの現行の Debian システムとコンパチブルな望ましいバージョンのバイナリーパッケージをビルド。

  - これは、簡便でない操作です(「安定版システムへのパッケージ移植」を参照下さい)。

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

Debian システム上でのレポジトリーを使ったパッケージ管理操作は Debian システム上にある多くのAPTを使うパッケージ管理ツールを使いできます。ここでは、`apt` /`apt-get` / `apt-cache` や `aptitude` といった3つの基本的なパッケージ管理ツールを説明します。

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

### 2.2.1. `apt` と `apt-get`/`apt-cache` と `aptitude` の比較

`aptitude` は筆者が主に使う非常に良いインタラクティブツールではありますが、注意すべき事実があることを知っておくべきです。

- `stable`(安定版) Debian システムにおいて、新リリースがあった後の新リリースシステムへのアップグレードに`aptitude` コマンドを使用することは推薦されません。

  - それには、"`apt full-upgrade`" か "`apt-get dist-upgrade`" を使うことが推薦されます。Bug #411280 参照下さい。

- `aptitude` コマンドは時折`testing`(試験版) や `unstable` (不安定版) Debian システム上でシステムアップグレードをしようとする際に、大量のパッケージ削除を提案することが時々あります。

  - この状況は多くのシステム管理者を驚かせて来ました。パニックしないで下さい。

  - このようなことは `gnome-core` の様なメタパッケージにより依存や推薦されるパッケージ間のバージョンのずれにより発生するようです。

  - この状況は `aptitude` コマンドのメニューから "未実行アクションの取り消し" を選択し、`aptitude` を終了し、"`apt full-upgrade`" を使うことで解決できます。

`apt-get` や `apt-cache` コマンドはAPTを使う最も基本的なパッケージ管理ツールです。

- `apt-get`/`apt-cache` はコマンドラインのユーザーインターフェースのみを提供します。

- `apt-get` はリリース間のような大掛かりなシステムアップグレードに最適です。

- `apt-get` は頑強で安定なパッケージリゾルバーを提供します。

- `apt-get`はハードウエアリソースへの要求が楽である。メモリーの消費は少なく、実行速度が早い。

- `apt-cache` はパッケージ名や説明に関して標準の regex を使った検索機能を提供します。

- `apt-get` と `apt-cache` は `/etc/apt/preferences` を使って複数のバージョンのパッケージを管理できますが、それはとても面倒です。

`apt` コマンドはパッケージ管理のための上位コマンドラインインターフェースです。基本的に `apt-get` や `apt-cache` 等のコマンドのラッパーで、インタラクティブな用途に良いオプションをデフォルトで有効にしてエンドユーザーインターフェース向けとなっています。

- `apt` は、`apt install` としてパッケージをインストールするとフレンドリーなプログレスバーを提供します。

- `apt` は、ダウンロードされたパッケージが上手くインストールされた後、デフォルトでキャッシュされた `.deb` パッケージを削除 します。

| ヒント
ユーザーは インタラクティブ 用途には `apt`(8) コマンドを使うことが推奨されますし、シェルスクリプト中では`apt-get`(8) や `apt-cache`(8) コマンドを使うことが推奨されます。

`aptitude` コマンドは最も多芸なAPTを使うパッケージ管理ツールです。

- `aptitude` はフルスクリーンのインタラクティブなテキストユーザーインターフェースを提供します。

- `aptitude` はコマンドラインのユーザーインターフェースも提供します。

- `aptitude` はインストールされたパッケージを検査したり利用可能なパッケージを探索したりするような日常のインタラクティブなパッケージ管理に最適です。

- `aptitude`はハードウエアリソースへの要求が厳しい。メモリーの消費は多く、実行速度も遅い。

- `aptitude` はパッケージメタデータ全てに関する拡張されたregex を使った探索を提供します。

- `aptitude` は `/etc/apt/preferences` を使わずに複数のバージョンのパッケージを管理できますし、それは非常に直感的です。

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

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

表2.6 `apt`(8) や `aptitude`(8) や `apt-get`(8) /`apt-cache`(8) を使うコマンドラインによる基本パッケージ管理操作

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

`apt` / `apt-get` と `aptitude` は大きな問題なく混用が可能です。

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

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

| 注記
`aptitude` コマンドはその拡張されたパッケージリゾルバーのような豊富な機能が同梱されていますが、この複雑さは Bug #411123 や Bug #514930 や Bug #570377 のようないくつかのリグレッションを引き起こしました (また起こしているかもしれません)。疑義のある場合には、`aptitude` コマンドに代えて `apt` や `apt-get` や `apt-cache` コマンドを使って下さい。

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

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

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

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

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

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

    $ sudo aptitude -u
    Password:

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

| ヒント
user の設定ファイルでなく root の設定ファイルを使いたい際には、上記の例で "`sudo aptitude ...`" の代わりに "`sudo -H aptitude ...`" を使います。

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

### 2.2.4. aptitude のキーバインディング

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

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

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

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

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

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

インタラクティブなフルスクリーンモードの `aptitude`(8) はパッケージリスト中のパッケージは以下の例のように表示されます。

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

上記の行は左から次に記すような意味です。

- "現状" フラグ (1番目の文字)

- "予定のアクション" フラグ (2番目の文字)

- "自動" フラグ (3番目の文字)

- パッケージ名

- "予定のアクション" に帰属されるディスク空間の使用の変化

- パッケージの現バージョン

- パッケージの候補バージョン

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

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

"`表示`" メニューの下にある数種のパッケージ表示が利用できます。

表2.9 aptitude の表示のリスト

表示 | ビューの説明
--- | ---
`パッケージ画面` | 表2.10「標準パッケージ画面の分類」を参照 (デフォールト)
`推奨を監査` | 何らかのインストール済みパッケージによって推薦されているがインストールされていないパッケージをリスト
`平坦なパッケージリスト` | パッケージを分類せずにリスト (regex とともに使用)
`Debtags 表示` | パッケージの debtags のエントリーにより分類したパッケージをリスト
`ソースパッケージ画面` | ソースパッケージごとに分けてパッケージのリストを表示

| 注記
パッケージの debtags によるタグ付け状況を改善するのにご協力下さい！

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

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

分類 | ビューの説明
--- | ---
`更新可能なパッケージ` | `section` → `area` → `package` と整理してパッケージをリスト
`新規パッケージ` | , ,
`インストール済みのパッケージ` | , ,
`インストールされていないパッケージ` | , ,
`廃止された、またはローカルで作成されたパッケージ` | , ,
`仮想パッケージ` | 同一機能のパッケージをリスト
`タスク` | タスクに一般的に必要な機能を持つパッケージのリスト

| ヒント
`Tasks` ビューはあなたのタスクに使うパッケージをいいとこ取りするのに使えます。

### 2.2.6. aptitude を使った探索方法

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

- シェルコマンドライン:

  - マッチするパッケージのインストール状態やパッケージ名や短い説明をリストをすには、"`aptitude search 'aptitude_regex'`"

  - パッケージの詳細説明のリストをするには、"`aptitude show 'package_name'`"

- 対話型フルスクリーンモード:

  - マッチするパッケージにパッケージビューを絞る、"`l`"

  - マッチするパッケージを探す、"`/`"

  - マッチするパッケージを逆方向に探す、"`\`"

  - 次を探す、"`n`"

  - 次を逆方向に探す、"`N`"

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

### 2.2.7. aptitude の regex 式

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

表2.11 aptitude の regex 式のリスト

拡張マッチ規則の説明 | regex 式
--- | ---
パッケージ名とのマッチ | `~n名前のregex`
記述とのマッチ | `~d記述のregex`
タスク名とのマッチ | `~tタスクのregex`
debtag とのマッチ | `~Gdebtagのregex`
メンテナとのマッチ | `~mmaintainerのregex`
パッケージセクションとのマッチ | `~sセクションのregex`
パッケージバージョンとのマッチ | `~Vバージョンのregex`
アーカイブ (archive) とのマッチ | `~A{trixie,forky,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`
type の壊れた依存関係を宣言しているパッケージとマッチ | `~Btype`
type の壊れた依存関係を宣言している pattern パッケージとマッチ | `~D[type:]pattern`
type の壊れた依存関係を宣言している pattern パッケージとマッチ | `~DB[type:]pattern`
pattern マッチするパッケージが type の依存関係を宣言しているパッケージとマッチ | `~R[type:]pattern`
pattern マッチするパッケージが type の壊れた依存関係を宣言しているパッケージとマッチ | `~RB[type:]pattern`
他のインストール済みパッケージが依存するパッケージとマッチ | `~R~i`
他のインストール済みパッケージが一切依存しないパッケージとマッチ | `!~R~i`
他のインストール済みパッケージが依存もしくは推薦するパッケージとマッチ | `~R~i|~Rrecommends:~i`
フィルターされたバージョンの pattern とマッチ | `~S filter pattern`
常に全てのパッケージにマッチ (真) | `~T`
どのパッケージにもマッチしない (偽) | `~F`

- regex 部分は、"`^`" や "`.*`" や "`$`" などを使う `egrep`(1) や `awk`(1) や `perl`(1) といった典型的な Unix 的テキストツールで使われる ERE と同様です。

- 依存関係を表す type はパッケージの相互関係を指定する (depends, predepends, recommends, suggests, conflicts, replaces, provides) の内の1つです。

- デフォールトの依存 タイプ は "depends" です。

| ヒント
regex_pattern がヌル文字列の場合は "`~T`" をコマンドの直後に使って下さい。

次がショートカットです。

- "`~Pterm`" == "`~Dprovides:term`"

- "`~Cterm`" == "`~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.8. aptitude による依存関係の解決

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

`aptitude` コマンドの"自動インストール" 挙動を制御するフラグは `apt` パッケージ中の `apt-mark`(8) コマンドを用いても操作できます。

### 2.2.9. パッケージ活動ログ

パッケージ活動履歴はログファイルで確認できます。

表2.12 パッケージ活動のログファイル

ファイル | 内容
--- | ---
`/var/log/dpkg.log` | 全パッケージ活動の `dpkg` レベルの活動ログ
`/var/log/apt/term.log` | 汎用 APT 活動ログ
`/var/log/aptitude` | `aptitude` コマンド活動ログ

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

## 2.3. aptitude 操作例

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

### 2.3.1. 興味あるパッケージの探索

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

### 2.3.2. 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.3. regex マッチをしての閲覧

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

### 2.3.4. パッケージの完全削除

削除したパッケージが残した全ての設定ファイルを以下のようにして完全削除できます。

以下のコマンドの結果をチェックします。

    # aptitude search '~c'

もしリストされたパッケージが完全削除されても問題ないなら、以下のコマンドを実行します。

    # aptitude purge '~c'

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

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

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

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

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

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

1. `aptitude` を root としてインタラクティブに起動します。

2. "`u`" と "`U`" と "`f`" と "`g`" とタイプしてパッケージリストを更新しパッケージをアップグレードします。

3. パッケージ表示制限を "`~i(~R~i|~Rrecommends:~i)`" と入力するために "`l`" とタイプし、自動インストール済みとするように"`Installed Packages`" (インストール済みパッケージ) の上で "`M`" とでタイプします。

4. パッケージ表示制限を "`~prequired|~pimportant|~pstandard|~E`" と入力するために "`l`" とタイプし、手動インストールとなるよう "`m`" と "`Installed Packages`" (インストール済みパッケージ)の上でタイプします。

5. パッケージ表示制限を "`~i!~M`" と入力するために "`l`" とタイプし、"`Installed Packages`" (インストール済みパッケージ)の上で "`[`" とタイプしてパッケージを見えるようにした後で個々のパッケージの上で "`-`" とタイプして使っていないパッケージを削除します。

6. パッケージ表示制限を "`~i`" と入力するように "`l`" とタイプし、そして "`タスク`" の上で手動インストールとなるよう "`m`" とタイプします。

7. `aptitude` を終了します。

8. "`apt-get -s autoremove|less`" と root から起動して何が使われていないのか確認します。

9. `aptitude` とインタラクティブモードで再起動して必要なパッケージを "`m`" でマークします。

10. "`apt-get -s autoremove|less`" と root から再起動して削除対象が期待にかなっていることを再確認します。

11. "`apt-get autoremove|less`" と root から起動して使用していないパッケージを自動削除します。

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

### 2.3.6. システム全体のアップグレード

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

ソースリストの内容を新規リリースへ向けるように変更し、"`apt update; apt dist-upgrade`"コマンドを実行することでシステム全体のアップグレードができます。

安定版 `stable` リリースが `trixie` の期間中の、安定版 `stable` からテスト版 `testing` や不安定版 `unstable` にアップグレードするには、「Debian アーカイブの基本」にある ソースリスト例の "`trixie`" を "`forky`" か "`sid`" に置き換えます。

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

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

メーリングリストから最新情報を収集するとか常識を使うといった予防措置をしながらフルアップグレードをするべきです。

1. 前回の "リリースノート" を読みます。

2. 全システム (特にデーターや設定情報) をバックアップします。

3. ブートローダーが壊れたときのためにブートできるメディアを確保します。

4. システムを使っているユーザーに十分事前に通告します。

5. `script`(1) を使ってアップグレード活動を記録します。

6. 削除をされないように "`aptitude unmarkauto vim`" 等として、"unmarkauto" を重要なパッケージに適用します。

7. デスクトップタスクにあるパッケージ等を削除して、インストールされたパッケージを減らしてパッケージがコンフリクトする可能性を減らします。

8. "`/etc/apt/preferences`" ファイルを削除します (apt-pinning を無効化)。

9. 段階的にアップグレードしましょう: 旧安定版 `oldstable` → 安定版 `stable` → テスト版 `testing` → 不安定版 `unstable`。

10. ソースリストを更新して新アーカイブ対象に "`aptitude update`" を実行します。

11. "`aptitude install perl`" 等として、先に新規の中核的パッケージを必要に応じてインストールします。

12. "`apt-get -s dist-upgrade`" コマンドを実行して影響を確認します。

13. 最後に "`apt-get dist-upgrade`" コマンドを実行します。

| 注意
`stable` リリース間でアップグレードする際に Debian のメジャーリリースを飛ばすのは賢明ではありません。

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

| 注意
「リリースノート」は可能性ある全ケースをカバーしていないかもしれません。低レベル設定を変更した場合、あなたの次のアップグレードは "... segfault after upgrade ..." のように上手く行かないかもしてません。

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

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

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

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

表2.13 高度なパッケージ管理操作

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

| 注記
multi-arch 機能のあるパッケージに関して、一部のコマンドはアーキテクチャー名を必要があるかもしれません。例えば、`amd64` アーキテクチャーの `libglib2.0-0` パッケージの内容をリストするには "`dpkg -L libglib2.0-0:amd64`" を使います。

| 注意
"`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`" コマンドは ソースリストの中に "`deb-src`" エントリーが必要です。

- `dget`(1) や `debuild`(1) や `debi`(1) は `devscripts` パッケージが必要です。

- "`apt-get source`" を使った (再)パッケージ化の手続きは「安定版システムへのパッケージ移植」を参照下さい。

- `make-kpkg` コマンドは `kernel-package` パッケージが必要です (「カーネル」を参照下さい)。

- 一般的なパッケージ化に関しては「Debian パッケージ作成」を参照下さい。

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

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

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

### 2.4.3. パッケージ問題からの防御

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

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

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

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

最近は Debian サイトの https://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://deb.debian.org/debian/`" のような各 Debian ミラーサイトの "`dist/コード名`" の下に保存されています。そのアーカイブ構造はウェッブブラウザーで閲覧できます。6つのタイプの重要メタデーターがあります。

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

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

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

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

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

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

    Origin: Debian
    Label: Debian
    Suite: unstable
    Codename: sid
    Date: Sat, 14 May 2011 08:20:50 UTC
    Valid-Until: Sat, 21 May 2011 08:20:50 UTC
    Architectures: alpha amd64 armel hppa hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 sparc
    Components: main contrib non-free
    Description: Debian x.y Unstable - Not Released
    MD5Sum:
     bdc8fa4b3f5e4a715dd0d56d176fc789 18876880 Contents-alpha.gz
     9469a03c94b85e010d116aeeab9614c0 19441880 Contents-amd64.gz
     3d68e206d7faa3aded660dc0996054fe 19203165 Contents-armel.gz
    ...

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

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

- 暗号手法による署名ファイル "`Release.gpg`" は真正のトップレベルの "`Release`" ファイルと秘密の Debian アーカイブキーから作成されます。

- 公開の Debian アーカイブキーは最新の `debian-archive-keyring` パッケージによってローカルに導入されます。

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

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

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

もしソースリストの記載内容が "`signed-by`" オプションを指定した場合には、指定された公開キーでダウンロードしたトップレベルの "`Release`" ファイルを指定した公開キーで検証されます。これは、ソースリスト が非 Debian アーカイブを含むとき非常に有用です。

| ヒント
APT キーの管理に `apt-key`(8) コマンドを用いることは非推奨です。

これとは別に、`gpg` を用いて "`Release.gpg`" ファイルと ftp-master.debian.org に掲示された公開アーカイブキーで "`Release`" ファイルの整合性を手動で検証できます。

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

| ヒント
アーカイブレベルの "`Release`" ファイルが `apt_preferences`(5) のルールに使われます。

"`http://deb.debian.org/debian/dists/unstable/main/binary-amd64/Release`" や "`http://deb.debian.org/debian/dists/sid/main/binary-amd64/Release`" 等の ソースリストが指定する全てのアーカイブロケーションにはアーカイブレベルの次に示すような "`Release`" ファイルがあります。

    Archive: unstable
    Origin: Debian
    Label: Debian
    Component: main
    Architecture: amd64

| 注意
"`Archive:`" スタンザには、Debian アーカイブではスイート名 ("`stable`" や "`testing`" や "`unstable`" 等) が使われますが、Ubuntu アーカイブではコード名 ("`trusty`" や "`xenial`" や "`artful`" 等) が使われます。

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

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

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

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

`aptitude` や `apt-get` や `synaptic` や `apt-file` や `auto-apt` 等の APT ツールが使われる際には Debian アーカイブ情報を含むメタデーターのローカルコピーを更新する必要があります。この様なローカルのコピーはソースリスト中の`ディストリビューション (distribution)` と`エリア (area)` と`アーキテクチャー (architecture)` の名前に対応する以下のファイル名です (「Debian アーカイブの基本」を参照下さい)。

- "`/var/lib/apt/lists/deb.debian.org_debian_dists_ディストリビューション_Release`"

- "`/var/lib/apt/lists/deb.debian.org_debian_dists_ディストリビューション_Release.gpg`"

- "`/var/lib/apt/lists/deb.debian.org_debian_dists_ディストリビューション_エリア_binary-アーキテクチャー_Packages`"

- "`/var/lib/apt/lists/deb.debian.org_debian_dists_ディストリビューション_エリア_source_Sources`"

- "`/var/cache/apt/apt-file/deb.debian.org_debian_dists_ディストリビューション_Contents-アーキテクチャー.gz`" (`apt-file` 用)

最初の4つのタイプのファイルは全ての適切な APT コマンド間で共有されておりコマンドラインから "`apt-get update`" や "`aptitude update`" によって更新されます。もしソースリスト中に "`deb`" が指定されていれば "`Packages`" メタデーターが更新されます。もしソースリスト中に "`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/archives`" に貯蔵されます。

`aptitude` では、このキャッシュファイルのクリーニングポリシーは "`Options`" → "`Preferences`" の下で設定でき、 "`Actions`" の下の "`Clean package cache`" か "`Clean obsolete files`" メニューによって強制実行できる。

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

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

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

パッケージタイプ | 名前の構造
--- | ---
バイナリーパッケージ (所謂 `deb`) | `パッケージ名_アップストリームのバージョン-debianのレビジョン_アーキテクチャー.deb`
Debianインストーラー用のバイナリーパッケージ (所謂`udeb`) | `パッケージ名_アップストリームのバージョン-debianのレビジョン_アーキテクチャー.udeb`
ソースパッケージ (アップストリームのソース) | `パッケージ名_アップストリームのバージョン-debianのレビジョン.orig.tar.gz`
`1.0` ソースパッケージ (Debian の変更部分) | `パッケージ名_アップストリームのバージョン-debianのレビジョン.diff.gz`
`3.0 (quilt)` ソースパッケージ (Debian の変更部分) | `パッケージ名_アップストリームのバージョン-debianのレビジョン.debian.tar.gz`
ソースパッケージ (内容記述) | `パッケージ名_アップストリームのバージョン-debianのレビジョン.dsc`

| ヒント
ここでは基本的なパッケージフォーマットのみが記述されています。詳細は `dpkg-source`(1) を参照下さい。

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

名前の部分 | 使用可能文字 (ERE regex) | 存在
--- | --- | ---
`パッケージ名` | `[a-z0-9][-a-z0-9.+]+` | 必須
`エポック:` | `[0-9]+:` | 任意
`アップストリームのバージョン` | `[-a-zA-Z0-9.+:]+` | 必須
`debianのレビジョン` | `[a-zA-Z0-9.+~]+` | 任意

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

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

### 2.5.9. dpkg コマンド

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

"`パッケージ名`"というパッケージをインストールする際に、`dpkg` は次に記す順番でパッケージを処理します。

1. deb ファイルを解凍 ("`ar -x`" と等価)

2. `debconf`(1) を使い "`package_name.preinst`" を実行

3. システムにパッケージ内容をインストール ("`tar -x`" と等価)

4. `debconf`(1) を使い "`package_name.postinst`" を実行

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

表2.17 `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) を用いて何らかの重畳するプログラムを平和裏にインストールするメカニズムがあります。例えば `vim` と `nvi` の両方のパッケージがインストールされた状況下で `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`" が指定されファイルが存在すれば、即座に新たな所有者やモードに設定されます。

| 注意
パッケージが所有するファイルの所有者やモードをシステム管理者が `chmod` や `chown` コマンドを用いて直接変更しても次回パッケージアップグレードによりリセットされます。

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

### 2.5.12. dpkg-divert コマンド

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

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

テスト版 `testing` や 非安定版 `unstable` システムを実行する時には、管理者には壊れたパッケージ管理状況から復元できることが望まれます。

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

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

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

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

### 2.6.2. パッケージデーターのキャッシングエラー

APT を使うと、"GPG error: ... invalid: BADSIG ..." 等の首を傾げたくなるエラーがパッケージデーターのキャッシュエラーで引き起こされます。

全てのキャッシュデーターを "`sudo rm -rf /var/lib/apt/*` " で削除しもう一度トライしましょう。(`apt-cacher-ng` が使われた場合には "`sudo rm -rf /var/cache/apt-cacher-ng/*` " も実行しましょう。)

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

`dpkg` は非常に低レベルフのパッケージツールなので、ネットワーク接続なしでも機能します。

`foo` パッケージが壊れていて修復の必要があると仮定しましょう。

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

もしブート不可能な場合には、以下のコマンドを使ってインストールすることもできます。

    # dpkg -i /path/to/foo_old_version_arch.deb

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

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

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

### 2.6.4. 依存関係の欠落により失敗したインステレーション

依存パッケージをインストールせず"`sudo dpkg -i ...`" でパッケージを強制インストールした場合、パッケージのインストールは部分インストールとなり失敗します。

"`sudo dpkg -i ...`" を繰り返し使って全ての依存パッケージをインストールします。

    # apt --fix-broken install

そして、全ての部分的にインストールされたパッケージを以下のコマンドで設定します。

    # dpkg --configure -a

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

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

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

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

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

    $ sudo dpkg -P old-package

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

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

"`パッケージ名`" のパッケージスクリプトの問題に関しては、以下のパッケージスクリプトの内容を確認するべきです。

- "`/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.7. パッケージセレクションの復元

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

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

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

最低限の (デスクトップ) システムを再インストールします。

    # mkdir -p /path/to/old/system

"`/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. パッケージ管理のヒント

簡単のため、本セクション中のソースリスト例は`trixie` リリース後の１行スタイルの "`/etc/apt/sources.list`" として示されています。

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

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

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

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

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

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

`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";

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

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

### 2.7.4. Updates と Backports

`stable` のためのアップグレードパッケージを提供する、stable-updates (安定版 `stable` リリースが `trixie` の期間中の "`trixie`-updates") や backports.debian.org アーカイブがあります。

これらのアーカイブを使うには、以下に示すように "`/etc/apt/preferences`" ファイル中に全ての必要なアーカイブをリストします。

    deb http://deb.debian.org/debian/ trixie main non-free-firmware contrib non-free
    deb http://security.debian.org/debian-security trixie-security main non-free-firmware contrib non-free
    deb http://deb.debian.org/debian/ trixie-updates main non-free-firmware contrib non-free
    deb http://deb.debian.org/debian/ trixie-backports main non-free-firmware contrib non-free

"`/etc/apt/preferences`" ファイル中に Pin-Priority 値を明示的に設定する必要はありません。より新しいパッケージが利用可能となった場合はいつも、デフォルトの設定によりもっとも合理的なアップグレードがなされます (「アーカイブレベルの "Release" ファイル」 参照下さい)。

- 全てのインストールされている古いパッケージが `trixie-updates` からのより新しいパッケージにアップグレードされます。

- `trixie-backports` からインストールしされた古いパッケージのみが `trixie-backports` からのより新しいパッケージにアップグレードされます。

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

    $ sudo apt-get install -t trixie-backports package-name

| 警告
backports.debian.org アーカイブから多すぎるパッケージをインストールしてはいけない。そんなことをするとパッケージ依存関係合併症を引き起こすかもしれません。代替解決策は、「矛盾した要求への対処法」を参照下さい。

### 2.7.5. 外部のパッケージアーカイブ

| 警告
外部のパッケージはあなたのシステムのルート権限を獲得することを意識するべきです。信頼できる外部のパッケージアーカイブのみを使うべきです。代替策は「矛盾した要求への対処法」を参照下さい。

ソースリストに Debian コンパチブルな外部パッケージアーカイブを加え "`/etc/apt/trusted.gpg.d/`" ディレクトリーそのアーカイブキーファイルを置くことで、セキュアー APT で そのアーカイブが使えます。`sources.list`(5) と `apt-secure`(8) と `apt-key`(8) を参照下さい。

### 2.7.6. apt-pinning を使わない混合のアーカイブソースからのパッケージ

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

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

1. "`/etc/apt/sources.list`" ファイルを変更し、単一の "`unstable`" エントリーのみにします。

2. "`aptitude update`" を実行します。

3. "`aptitude install パッケージ名`"の実行します。

4. `testing` のためのオリジナルの "`/etc/apt/sources.list`" ファイルを復元します。

5. "`aptitude update`" を実行します。

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

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

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

- 非バイナリーパッケージ("`Architecture: all`")のインストールは比較的安全です。

  - 文書パッケージ: 特段の要件無し

  - インタープリタプログラムパッケージ: 互換性あるインタープリタ環境が利用可能

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

  - ライブラリー ("`libc`" 等) のバージョン互換性

  - 関連ユーティリティープログラムのバージョン互換性

  - カーネル ABI 互換性

  - C++ の ABI 互換性

  - …

| 注記
パッケージを比較的安全にインストールできるようにするために、一部の商用 non-free バイナリープログラムパッケージは完全に静的にリンクされたライブラリーとともに提供される事があります。そんなパッケージに関しても ABI 互換性等の問題は確認するべきです。

| 注記
短期的に壊れたパッケージを回避するため以外は、非 Debian アーカイブからバイナリーパッケージをインストールするのは大体良くないアイデアです。あなたの現行の Debian システムとコンパチブルな、全ての利用可能な安全な技術的解決策を探索すべきです(「矛盾した要求への対処法」を参照下さい)。

### 2.7.7. apt-pinning で候補バージョンを調整

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

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

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

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

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

アーカイブレベルの Release ファイル (「アーカイブレベルの "Release" ファイル」を参照下さい) が `apt_preferences`(5) のルールに使われます。だから、apt-pinning は normal Debian archives や security 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-pinning テクニックの説明を次にします。

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

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

表2.18 apt-pinning テクニックに関する特記すべき Pin-Priority 値をリストします。

Pin-Priority | パッケージに関する apt-pinning 効果
--- | ---
1001 | パッケージのダウングレードになる場合でもパッケージをインストールする
990 | ターゲットのリリースアーカイブのデフォルトとして使用
500 | ノーマルアーカイブのデフォルトとして使用
100 | NotAutomatic かつ ButAutomaticUpgrades アーカイブのデフォルトとして使用
100 | インストール済みパッケージに使用
1 | NotAutomatic アーカイブのデフォルトとして使用
-1 | たとえ推奨 (Recommend) されても、パッケージを絶対にインストールしない

ターゲットのリリースアーカイブは"`apt-get install -t testing some-package`" のようにコマンドラインオプションによって設定できます。

アーカイブ中のアーカイブレベルの Release ファイル (「アーカイブレベルの "Release" ファイル」を参照下さい) に "`NotAutomatic: yes`" と "`ButAutomaticUpgrades: yes`" が含まれると NotAutomatic かつ ButAutomaticUpgrades アーカイブが設定されます。アーカイブ中のアーカイブレベルの Release ファイルに "`NotAutomatic: yes`" だけが含まれると NotAutomatic アーカイブが設定されます。

複数アーカイブソースの package に関する apt-pinning 状況は "`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: *`" として定義) はアーカイブへのパスの左側に、"`100 http://deb.debian.org/debian/ trixie-backports/main Packages`" 等としてリストされます。

### 2.7.8. "推奨 (Recommends)" によりパッケージがインストールされるのを阻止

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

たとえ "推奨 (Recommends)" されていても自動的に特定のパッケージが引きこまれ無くしたいときには、"`/etc/apt/preferences`" ファイルを作成しその中に全てのパッケージを以下のように明示的にリストしなければいけません。

    Package: package-1
    Pin: version *
    Pin-Priority: -1

    Package: package-2
    Pin: version *
    Pin-Priority: -1

### 2.7.9. `unstable` からのパッケージと共に、`testing` を追いかける

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

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

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

"`/etc/apt/preferences`" を以下のように設定します。

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

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

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

この設定では、通常の "`apt-get upgrade`" や "`apt-get dist-upgrade`" ("`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: 100`" の代わりに "`Pin-Priority: 1`" が用いられた場合は、"`/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` アーカイブからインストールしても今までいつも安全でした。

### 2.7.10. `experimental` からのパッケージと共に、`unstable` を追いかける

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

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

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

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

### 2.7.11. 緊急ダウングレード

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

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

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

次に記すような "`unstable`" を追跡する "`/etc/apt/sources.list`" ファイル中の行を探します。

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

それを `testing` を追いかけるように次と交換します。

    deb http://deb.debian.org/debian/ forky main contrib non-free

"`/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.12. equivs パッケージ

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

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

    Package: equivs
    Priority: optional
    Section: admin
    Description: Circumventing Debian package dependencies
     This package provides a tool to create trivial Debian packages.
     Typically these packages contain only dependency information, but they
     can also include normal installed files like other packages do.
     .
     One use for this is to create a metapackage: a package whose sole
     purpose is to declare dependencies and conflicts on other packages so
     that these will be automatically installed, upgraded, or removed.
     .
     Another use is to circumvent dependency checking: by letting dpkg
     think a particular package name and version is installed when it
     isn't, you can work around bugs in other packages' dependencies.
     (Please do still file such bugs, though.)

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

| 注意
ここに書かれた手順がシステムの違いのために追加の手動の努力無しにうまく行く保証はありません。

`stable` システムの部分アップグレードのためには、その環境内でソースパッケージを使ってパッケージをリビルドするのが好ましいです。こうすることでパッケージ依存関係による大掛かりなアップグレードをしないで済みます。

`stable` システムのための "`/etc/apt/sources.list`" ファイルに以下のエントリーを追加します。

    deb-src http://deb.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*

バックポートに必要な際には、`dpkg` や `debhelper` 等のツールチェインパッケージをバックポートパッケージを用いて更新します。

次を実行します。

    $ dch -i

"`+bp1`" を後ろに付けるなどして、"`debian/changelog`" 中でパッケージバージョンを先に進める

以下のようにしてパッケージをビルドしシステムにインストールします。

    $ debuild
    $ cd ..
    # debi foo*.changes

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

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

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

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

パッケージ | ポプコン | サイズ | 説明
--- | --- | --- | ---
`approx` | V:0, I:0 | 8308 | Debian アーカイブファイルのキャッシュプロキシサーバー (コンパイルされた OCaml プログラム)
`apt-cacher` | V:0, I:0 | 267 | Debian パッケージとソースファイルのキャッシュプロキシ (Perl プログラム)
`apt-cacher-ng` | V:4, I:4 | 1968 | ソフトウェアーパッケージの頒布ためのキャッシュプロキシ (コンパイルされた C++ プログラム)

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

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

パッケージ管理に関しては以下の文書からさらに学習できます。

- パッケージ管理の一義的文書:

  - `aptitude`(8) と `dpkg`(1) と `tasksel`(8) と `apt`(8) と `apt-get`(8) と `apt-config`(8) と `apt-secure`(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 アーカイブに関する文書:

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

  - "Debian 開発者リファレンス、第4章 Debian 開発者が利用可能なリソース 4.6 Debian アーカイブ"と、

  - "The Debian GNU/Linux FAQ, Chapter 6 - The Debian FTP archives".

- Debian ユーザー向けの Debian パッケージ作成の入門書:

  - "Debian Maintainer 向け案内書".

第1章 GNU/Linux チュートリアル |  | 第3章 システムの初期化