第2章 Debian パッケージ管理

目次

2.1. Debian パッケージ管理の前提条件
2.1.1. Debian パッケージ管理システム
2.1.2. パッケージ設定
2.1.3. 基本的な注意事項
2.1.4. 永遠のアップグレード人生
2.1.5. Debian アーカイブの基本
2.1.6. Debian は 100% フリーソフトウェアーです
2.1.7. パッケージ依存関係
2.1.8. パッケージ管理のイベントの流れ
2.1.9. パッケージ管理のトラブルへの応急対処法
2.1.10. Debian パッケージの選択方法
2.1.11. 矛盾した要求への対処法
2.2. 基本的パッケージ管理操作
2.2.1. aptapt-get/apt-cacheaptitude の比較
2.2.2. コマンドラインによる基本的なパッケージ管理操作
2.2.3. aptitude のインタラクティブな使用
2.2.4. aptitude のキーバインディング
2.2.5. aptitude の下でのパッケージの表示
2.2.6. aptitude を使った探索方法
2.2.7. aptitude の regex 式
2.2.8. aptitude による依存関係の解決
2.2.9. パッケージ活動ログ
2.3. aptitude 操作例
2.3.1. 興味あるパッケージの探索
2.3.2. regex にマッチするパッケージ名のパッケージをリスト
2.3.3. regex マッチをしての閲覧
2.3.4. パッケージの完全削除
2.3.5. 自動 / 手動インストール状態の整理
2.3.6. システム全体のアップグレード
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. 重複するファイルを持つ相異なるパッケージ
2.6.5. 壊れたパッケージスクリプトの修正
2.6.6. dpkg コマンドを使っての救済
2.6.7. パッケージセレクションの復元
2.7. パッケージ管理のヒント
2.7.1. 誰がパッケージをアップロードしたのか?
2.7.2. APT のよるダウンロードバンド幅の制限
2.7.3. パッケージの自動ダウンロードとアップグレード
2.7.4. Updates と Backports
2.7.5. 外部のパッケージアーカイブ
2.7.6. apt-pinning を使わない混合のアーカイブソースからのパッケージ
2.7.7. apt-pinning で候補バージョンを調整
2.7.8. "推奨 (Recommends)" によりパッケージがインストールされるのを阻止
2.7.9. unstable からのパッケージと共に、testing を追いかける
2.7.10. experimental からのパッケージと共に、unstable を追いかける
2.7.11. 緊急ダウングレード
2.7.12. equivs パッケージ
2.7.13. 安定版システムへのパッケージ移植
2.7.14. APT のためのプロキシサーバー
2.7.15. パッケージ管理の追加参考文書
[注記] 注記

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

APT システムのデーターソースは本文書中では集合的にソースリストと表記されます。これは、"/etc/apt/sources.list" ファイルか、 "/etc/apt/sources.list.d/*.list" ファイルか、 "/etc/apt/sources.list.d/*.source" ファイルの中の何処かに定義されます。

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

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

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

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

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

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

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

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


[警告] 警告

ランダムな混合のスイーツからパッケージをインストールしてはいけません。コンパイラーの 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 システムの長い安定性の歴史それ自体は何の保証でもありません。

[注意] 注意

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

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

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

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

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

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

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

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

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

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

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

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

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

[注意] 注意

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

[ヒント] ヒント

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

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

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

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

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

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

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

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

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

Types: deb deb-src
URIs: http://security.debian.org/debian-security/
Suites: bookworm-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/*.source" ファイルです。

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

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

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

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

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

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

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

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

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

[ヒント] ヒント

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

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


[注意] 注意

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

[注意] 注意

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

[ヒント] ヒント

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

[注記] 注記

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


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

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

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


コード名の歴史は、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 にて)

  • アーカイブの同期のタイミング問題 (testingunstable の両方にて)。

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

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

[注意] 注意

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

[ヒント] ヒント

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[注記] 注記

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

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

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

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

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

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

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

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

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

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

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

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 にあります。

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

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

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

$ cd package_name
$ pager README.Debian
$ mc

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

apt コマンドはパッケージ管理のための上位コマンドラインインターフェースです。基本的に apt-getapt-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 を使わずに複数のバージョンのパッケージを管理できますし、それは非常に直感的です。

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-getaptitude は大きな問題なく混用が可能です。

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

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

[注記] 注記

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

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


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

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


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

[ヒント] ヒント

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

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

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

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

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

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

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

  • パッケージ名

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

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

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

[ヒント] ヒント

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

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

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


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


[ヒント] ヒント

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

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{bookworm,trixie,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" を参照下さい。

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

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

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

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

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

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

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

  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" を押すのも一案で、大量ファイル除去となる事態が回避できます。

[注記] 注記

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

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

安定版 stable リリースが bookworm の期間中の、安定版 stable からテスト版 testing や不安定版 unstable にアップグレードするには、「Debian アーカイブの基本」にある ソースリスト例の "bookworm" を "trixie" か "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 等には特別な配慮が必要でした。

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

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) 参照下さい) はエキスパートだけが使うようにできています。十分にその影響を理解せずに使うとシステム全体を壊してしまうかもしれません。

以下を承知下さい。

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

[注記] 注記

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

最近は 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) を使います。

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

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


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

[ヒント] ヒント

セキュアー 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" ファイルと "/etc/apt/trusted.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" ファイルの整合性を手動で検証できます。

[ヒント] ヒント

アーカイブレベルの "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" 等) が使われます。

experimentalbookworm-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 で候補バージョンを調整」を参照下さい)。

aptitudeapt-getsynapticapt-fileauto-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_ディストリビューション_エリア_source_Sources"

  • "/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" のローカルコピーがデフォールトでは異なるところにあります。)

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


[ヒント] ヒント

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


[注記] 注記

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

[注記] 注記

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

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 コマンドです。

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

[注意] 注意

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

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

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

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

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

[注意] 注意

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

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

$ sudo dpkg -P old-package

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

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

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

# dpkg -i /path/to/foo_old_version_arch.deb
[ヒント] ヒント

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

ハードディスクからブートできない場合は、他の方法でのブート方法を考えるべきです。

  1. Debian インストーラー (debian-installer) の CD を使ってレスキューモードでブートします。

  2. ブートできないハードディスク上のシステムを "/target" にマウントします。

  3. 古いバージョンの foo パッケージを以下のようにしてインストールします。

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

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

[ヒント] ヒント

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

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

[注記] 注記

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

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

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

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

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

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

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

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

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

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

$ sudo apt-get install -t bookworm-backports package-name
[警告] 警告

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

[注意] 注意

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

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

[注記] 注記

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

[注記] 注記

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

[警告] 警告

初心者のユーザーによる 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-pinningnormal 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-pinning テクニックの説明を次にします。

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

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


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

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

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

[警告] 警告

初心者のユーザーによる apt-pinning の利用は大トラブル発生を間違いなく起こします。絶対必要な時以外は 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 アーカイブからインストールしても今までいつも安全でした。

[警告] 警告

初心者のユーザーによる apt-pinning の利用は大トラブル発生を間違いなく起こします。絶対必要な時以外は 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/ trixie 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 やネットワーク関係のパッケージやそれらの設定ファイルには特に注意が必要です。

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 をチェック下さい。


[注意] 注意

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