依存関係を壊さずにDebian 12をTestingに移行する方法

具体例：マヤは開発用にDebian 12 Bookwormワークステーションを管理しています。彼女はDebian Testingの最新パッケージを使いたいのですが、APTを中途半端なパッケージセットのまま放置することはできません。最も安全な方法は、まず現在サポートされている安定版リリースを順に試してから、クリーンな安定版システムを現在のTestingコードネームに切り替えることです。この例は慎重な手順を説明するものであり、実際のアップグレードの報告でも、すべてのマシンが同じパッケージプランを持つことを保証するものでもありません。

2026年10月6日現在、DebianはDebian 13「Trixie」を安定版、Debian 14「Forky」をテスト版としています。Debianのテスト版に関するガイダンスでは、現在の安定版リリースからテスト版に移行することを推奨しており、古い安定版リリースから始めると予期しないエラーが発生する可能性があると警告しています。Bookwormをインストールしている場合は、リポジトリをForkyに変更する前に、公式のBookwormからTrixieへのアップグレード手順に従ってください。Debianが新しい安定版リリースを公開するとテスト版のコードネームが変わるため、作業当日にリリースページを再度確認してください。

なぜ依存関係を段階的に変更するのか？

APT は、システムに設定されているパッケージ インデックスとリリース スイートを使用して依存関係を解決します。古いインストール環境を直接 Testing に指定すると、APT はコア ライブラリ、カーネル、デスクトップ、ファームウェア、サードパーティ パッケージなど、複数の箇所にわたる変更を一度に提案する場合があります。シミュレーションによって疑わしい計画を明らかにすることはできますが、サポートされていない開始点を安全にすることはできません。

テストは常に変化するものです。パッケージはアーカイブの基準を満たした後、Unstable から移行されますが、一時的な依存関係のギャップや不具合が発生する可能性があります。また、Debian は、Stable に対して提供しているような永続的なセキュリティサポートを Testing に対しては提供していません。この方法は、回避可能なパッケージの競合を減らすことはできますが、Testing を Stable と同等の信頼性にしたり、将来発生するすべての不具合を防いだりすることはできません。

具体例：マヤのブックワームマシンを準備する

1. リリースの開始とパッケージの状態を確認します

マヤはまず、これがDebianそのものであることを確認し、現在のシステム状態を記録します。彼女は、何かを編集する前に、現在のリリース詳細とリポジトリファイルを読み込みます。

cat /etc/os-release
cat /etc/debian_version
apt-cache policy
dpkg --audit
apt-get check
apt-mark showhold

彼女は/etc/apt/sources.list、 、 内のすべてのファイル、およびと/etc/apt/sources.list.d/の APT 設定を確認します。目的は、アップグレード中に混乱が生じる前に、ベンダーリポジトリ、ローカルでビルドされたパッケージ、固定リリース、および保留中のパッケージを特定することです。 がパッケージ構成の未完了を報告したり、依存関係の破損を報告したりした場合、Maya はディストリビューションの変更を重ねるのではなく、まず Bookworm のその状態を修正します。/etc/apt/preferences/etc/apt/preferences.d/dpkg --auditapt-get check

2. リリースを変更する前に復旧を可能にする

パッケージソースに手を加える前に、Mayaは個人データと重要な構成（該当する場合はアプリケーションデータベースやサービスデータを含む）のテスト済みバックアップを作成します。ディスクイメージ全体またはVMスナップショットがあれば、オペレーティングシステムを復元できますが、ホームディレクトリのコピーだけでは復元できません。また、ローカルコンソールへのアクセス、起動可能なレスキューメディア、十分な空き容量、ネットワーク接続が正常であることを確認し/ます。/var/boot

マシンがリモートにある場合は、ダウンタイムをスケジュールし、可能であれば帯域外コンソールを使用します。ネットワークを再起動したり、SSHコンポーネントを交換したりするパッケージのアップグレードは、リモートセッションを切断する可能性があります。重要なサーバーの場合、Mayaはまずクローンで一連の手順全体をテストします。Debianのリリースノートには準備と復旧に関するガイダンスが記載されているため、各リリースのアップグレード前に必ず読んでください。

3. サポートされているBookwormからTrixieへのアップグレードを完了します。

Mayaは、公式のDebian 13リリースノートに記載されているBookwormからTrixieへのアップグレード手順に従います。これには、サードパーティのアーカイブ、APTの設定、パッケージの状態、および利用可能なディスク容量の確認が含まれます。彼女は、すべてのソースをForkyに書き換えることでBookwormがサポートするアップグレード手順をスキップしません。Debianは、Debian 12からDebian 13へのアップグレードについて明確に文書化しています。システムに適用される可能性のある正確なパッケージと構成のプロンプトについては、そのリリース固有の文書を参照してください。

マシンのアップグレードが完了したら、彼女はTrixieを再起動し、正常に起動することを確認します。重要なサービス、ネットワークアクセス、ストレージのマウント、グラフィックまたはデスクトップへのログイン、ファームウェアに依存するハードウェアなどをチェックします。このチェックポイントは重要です。問題があれば、テストを開始する前に、単一のリリース移行における問題を診断できるからです。

検証済みの安定版システムをテスト版に切り替える

4. 混在または古いリポジトリエントリを削除する

Trixie 上でシステムが正常に動作すると、Maya はその APT ソースファイルと設定ファイルのコピーを保存します。サードパーティのリポジトリと Trixie 固有のバックポートまたは更新エントリを一時的に無効にします。明確なピン留めポリシーなしに安定版、テスト版、不安定版を混在させると、ライブラリの不一致や依存関係の競合が発生する可能性があります。Debian 以外のベンダーのパッケージは Forky 用にまだ存在しない場合があるため、Maya は Trixie リポジトリが適切であると想定するのではなく、各ベンダーの互換性情報を確認します。

現在のインストール環境では、ソースは古い1行形式またはdeb822形式のいずれかを使用している可能性があります。既に使用されている形式を編集し、 Testingアップグレードの開始時に.sourcesアクティブなDebianエントリがまだbookwormまたはを指していないことを確認してください。trixie

5. DebianのメインアーカイブをForkyに指定する

この日付指定の例では、Forky は現在のテスト用コードネームです。 のような deb822 ソースファイルは、/etc/apt/sources.list.d/debian.sources次の構造を使用できます。インストールに一致するコンポーネントを保持します。この例には、一般的なファームウェアと非フリー領域が含まれていますが、すべてのシステムで自動的に有効になるわけではありません。

Types: deb
URIs: https://deb.debian.org/debian
Suites: forky
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

既存の設定を検査せずに、このスタンザをコピーしないでください。システムに必要なミラーリングの選択とコンポーネントを保持し、重複する Debian エントリは削除またはコメントアウトしてください。Forky がtesting安定版になった後も引き続き使用する予定がある場合は、移動エイリアスの使用を避けてください。コードネームは Forky のリリース移行を追跡し、スイート名はtesting将来的にどのリリースが Testing になるかに応じて変更されます。

テスト環境では、Stable のセキュリティ URL をそのまま使用したりtrixie-security、推測で作成したセキュリティforky-securityスイートに置き換えたりしないでください。Debian の FAQ には、テスト環境では Stable と同じ専用のセキュリティアップデートが提供されないこと、修正が Unstable から移行される必要がある場合があり、タイミングが異なる場合があることが記載されています。読者は、現在の Debian Testing のガイダンスと脆弱性情報を確認し、このサポートモデルが許容できるかどうかを判断してください。

6. インデックスを更新し、完全な依存関係の変更をシミュレートします。

ソースコードが編集されると、Maya はパッケージのメタデータを更新し、APT に完全なアップグレードをシミュレートするように要求します。

sudo apt update
sudo apt -s full-upgrade

このシミュレーションはレビュー手順であり、自動的に承認されるべき承認プロンプトではありません。Maya はインストール、アップグレード、保留、削除するパッケージのリストを読み上げます。提案によってデスクトップメタパッケージ、SSH サーバー、ブートローダー、ネットワークマネージャ、データベース、または依存している他のパッケージが削除される場合、関連性のないパッケージが大量に削除される場合、または APT が未解決の依存関係を報告する場合は、処理を停止します。原因が有効なサードパーティソース、保留、ピン留め、ディスク容量不足、または一時的なテスト移行であるかどうかを確認します。

保留中のパッケージは、必ずしも破損しているわけではありません。保守的なupgrade操作では行われない依存関係の変更が必要になる場合があります。パッケージ数をゼロにするためだけに、ライブラリを強制的にインストールしたり、メタパッケージを削除したりしないでください。プランが理解できない場合は、アーカイブ移行が落ち着くまで待つか、関連するDebianパッケージのバグ情報または移行情報を参照するか、Stableバージョンを使い続けてください。

アップグレードは段階的に適用し、レビューを実施します。

7. 保守的なアップグレードを実行し、その後、完全アップグレードを再度検討する。

シミュレーションが妥当でバックアップが最新である場合、Maya はまずインストール済みのパッケージを削除しないアップグレードを実行します。

sudo apt upgrade --without-new-pkgs

彼女は設定ファイルに関する質問を注意深く読み、ローカルでの変更内容を記録します。そして、パッケージプランが変更されている可能性があるため、再度シミュレーションを実行します。

sudo apt -s full-upgrade

提案された人員削減や追加が理にかなっている場合にのみ、彼女は実際の業務を遂行する。

sudo apt full-upgrade

full-upgradeリリース移行を完了するために、新しい依存関係をインストールしたり、パッケージを削除したりできます。そのため、シミュレーションと人間によるレビューが重要になります。説明のつかない削除が提案されたり、依存関係のエラーで失敗した場合、Maya は停止して正確な出力を保存します。ランダムなapt --fix-broken install強制バージョン選択や手動ライブラリ削除を連鎖させることはありません。これらの操作は不整合を悪化させる可能性があるためです。まず、APT のエラー、ソース構成、保留、パッケージの状態を調べ、原因を理解してから再試行してください。

パッケージの解凍と設定中は、マシンに電源を供給し、ネットワークに接続したままにしてください。同時に別のパッケージマネージャを起動しないでください。処理が中断された場合は、発生したエラーに対する復旧手順に従い、パッケージデータベースの状態を確認してから、保留中のパッケージ設定を完了してください。

8. 再起動し、依存関係を確認し、互換性のあるリポジトリのみを復元します。

APTが未解決のエラーなく完了すると、Mayaはパッケージの状態を確認し、必要に応じて再起動します。

sudo dpkg --audit
sudo apt-get check
sudo apt update
sudo reboot

再起動後、彼女は でインストール済みのリリースを確認し/etc/os-release、 で期待どおりのカーネルが実行されていることを確認し、uname -rを確認し、重要なアプリケーションとサービスをテストします。 とでsystemctl --failed最近のパッケージアクティビティを調べることができます。 システムが起動しなくなったり、ネットワークが利用できなくなったり、重要なサービスが失敗したりした場合は、APT の実行が成功しただけでは十分ではありません。/var/log/apt/history.log/var/log/dpkg.log

Debianパッケージが正常に動作していることを確認した後、彼女はサードパーティのリポジトリを一つずつ再有効化することを検討し、ベンダーがForkyのサポートを文書化した場合に限る。その後、彼女はapt updateアップグレードを実行する前に、そのアップグレードをシミュレーションする。マシンが通常の使用で安定するまで、彼女はリカバリバックアップを保持する。

移行が完了したかどうかを判断する方法

マヤは、マシンが想定どおりのTestingコードネームで起動し、dpkg --auditクリーンな状態であり、apt-get check依存関係の破損が報告されず、意図したリポジトリからのAPTアップデートが署名エラーやリリースエラーなく完了し、重要なワークロードが独自のチェックに合格した場合に、移行が完了したと判断します。また、後日発生した不具合を追跡できるように、日付、ソースコードの変更、パッケージの削除、および手動による構成決定事項を記録します。

目的が単に新しいアプリケーションを導入することだけであれば、Stable版を使い続け、公式のバックポート、ベンダーサポート付きパッケージ、コンテナ、または隔離されたテスト環境を利用する方が、システムへの影響は少なくて済むでしょう。コンピュータが業務上重要な場合、インターネットに接続されている場合、または迅速な復旧が不可能な場合は、一般的にDebian Stable版の方が適切な選択肢となります。テストは、アップデートを監視し、パッケージプランを読み、一時的なアーカイブや依存関係の問題をトラブルシューティングできるユーザー向けです。

公式資料

• Debianリリース：現在の安定版、テスト版、およびリリース状況
• Debian 13 リリースノート: Debian 12 Bookworm からのアップグレード
• Debian Wiki: Debian Testing およびアップグレードに関するガイダンス
• Debian FAQ：Stable、Testing、Unstableの選択
• Debianリファレンス：APT、アーカイブスイート、および依存関係管理