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

具体例：モーガンは個人開発用にDebian 12デスクトップを使用しており、プロジェクトのために新しいライブラリを必要としています。必要であれば再インストールも可能ですが、中途半端なアップグレードや重要なパッケージを削除するリゾルバプランは避けたいと考えています。これは架空の例であり、実際の移行やテスト結果ではありません。最も安全な実践的なアプローチは、段階的に移行を進め、APTのプランをシミュレーションし、提案された変更内容が理解できない場合はいつでも停止することです。

2026年10月9日現在、Debianは現在のテスト版ディストリビューションをForkyとしており、これはDebian 13「Trixie」の次のリリースとなります。Debianは、テスト版のセキュリティアップデートはセキュリティチームによってタイムリーに管理されていないと警告しています。テスト版は予備のデスクトップPCや開発用マシンでは役立つかもしれませんが、予測可能なセキュリティ対策や継続的な可用性を必要とするシステムには適していません。移行手順によって、すべての依存関係とアプリケーションが変更されないことを保証することはできません。

1. このコンピュータにとって、Debian Testingは適切な移行先でしょうか？

Testing には、依存関係のインストール可能性を維持するためのチェックなど、Unstable からの自動移行基準を満たしたパッケージが含まれています。ただし、すべてのパッケージにバグがない、またはすべてのデスクトップ構成が正常に動作するとは限りません。Debian プロジェクトは、Testing ディストリビューションの概要で、パッケージが Testing にどのように組み込まれるかを説明しています。Debian のセキュリティ FAQ では、移行の待機や移行によって修正が遅れる場合があると指摘しています。

業務上重要なデスクトップ、本番サーバー、または復旧手段のないマシンでは、Stable を使用してください。Morgan が想定する開発用デスクトップの場合、時折のパッケージ移行、一時的なアンインストール、および手動メンテナンスが計画に含まれているのであれば、Testing も許容範囲内かもしれません。目的が新しいアプリケーションを 1 つだけ使用することだけであれば、オペレーティングシステム全体を移行する前に、Debian Backports または他のサポートされているパッケージングオプションを確認してください。

2. リポジトリを変更する前にバックアップする必要があるものは何ですか？

パッケージリストのコピーだけでなく、復元可能なバックアップを作成してください。個人ファイル、アプリケーションデータ、暗号化回復キー、重要な設定、およびローカルでビルドされたパッケージはすべてバックアップしてください。仮想マシンの場合は、スナップショットを作成し、復元方法を確認してください。物理デスクトップの場合は、インストールメディアとテスト済みの起動方法を保管し、バックアップは別のメディアに保存してください。

後で比較できるように、現在のパッケージとソースの状態を記録しておきましょう。

dpkg --get-selections > ~/package-selections.txt
apt-mark showmanual > ~/manually-installed-packages.txt
sudo cp -a /etc/apt ~/apt-config-before-testing

これらの記録は変更内容を説明するのに役立ちますが、それだけでシステムを復元できるわけではありません。モーガンは、締め切り直前に開始するのではなく、APTプロンプトを確認して復旧するのに十分な時間があるときに移行を計画すべきです。

3. パッケージ管理とBookwormのインストールは正常に行われていますか？

新しいディストリビューションを導入する前に、既存の問題を解決してください。通常のDebian 12アップデートを完了し、カーネルまたはコアサービスが変更された場合は再起動し、デスクトップが正常に動作することを確認してください。その後、パッケージの状態、保留、およびリポジトリの起源を調べてください。

sudo dpkg --audit
sudo apt-get check
apt-mark showhold
apt-cache policy bash libc6 systemd

dpkg --audit部分的にインストールされたパッケージや、パッケージの状態が矛盾している場合は、その旨を報告しますapt-get check。また、現在のシステムにおける依存関係の問題もチェックします。保留中のパッケージは、安易に保留を解除するのではなく、内容を確認してください。移行期間中は、サードパーティのリポジトリを削除または無効化し、ベンダーのリポジトリ、ローカルファイル、またはソースビルドからインストールされたパッケージをメモしておきましょう。これらのパッケージは、Debian Testing に互換性のあるバージョンがない可能性があります。

システムに既に破損したパッケージ、未解決の設定、または混在したスイートが存在する場合は、その上にディストリビューションの変更を重ねないでください。まず現状を修正するか、別のパーティションまたはディスクにクリーンインストールを実行してください。ここで期待される結果は、パッケージの問題が把握されたベースラインであり、事前に完全に空の監査出力が提示されることではありません。

4. テスト前にBookwormからTrixieに移行すべきでしょうか？

はい、ドキュメントに記載されている Bookworm から Trixie へのアップグレード手順を中間段階として使用してください。Debian のリリースノートは、ある安定版リリースから次の安定版リリースへのアップグレードについて記述されており、準備、既知の問題、およびアップグレード後のタスクが記載されています。Debian 12 のBookworm リリースノートには、次のリリースへのアップグレード方法が記載されています。これらの手順に従って再起動し、マシンが現在の安定版で動作していることを確認してから、Testing に切り替えてください。

この段階的な手順により、既知のチェックポイントが設定され、障害発生時の特定が容易になります。メインデスクトップでBookwormのソースを直接Testingに変更してリリースノートをスキップしないでください。直接ジャンプはAPTで解決できる場合もありますが、これはドキュメントに記載されている安定版から安定版へのアップグレードパスではなく、複数のパッケージ移行が1つの変更にまとめられてしまい、レビューが難しくなります。安定版へのアップグレード自体が失敗したり、パッケージが未解決のまま残った場合は、そこで作業を中断してください。

5. 複数のテストスイートを混在させることなく、APTをテスト対象に向けるにはどうすればよいですか？

Trixie システムがクリーンアップされ、バックアップが完了したら、/etc/apt/sources.listおよび以下のすべてのファイルを検査します。サードパーティのリポジトリを一時的に無効にします。Debian の安定版スイートのエントリを統一的に置き換えます。APT ピンニングを意図的に理解していない限り、、、、および無関係なスイートが/etc/apt/sources.list.d/混在した状態にならないようにします。trixietrixie-securitytesting

Deb822ソースファイルは、ソースごとに1つのスタンザを使用します。メインのDebianアーカイブの簡略化された例は次のとおりです。

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

ご使用の環境に適したコンポーネントと署名者設定を保持してください。すべてのシステムですべてのコンポーネントが有効になっているわけではありません。現在のテスト配布版が今後の移行に自動的に追従するようにするには、スイート名を使用してくださいtesting。上記の日付時点では、これは Forky に解決されます。コード名を使用するとforky、代わりにそのリリース名に固定されます。Forky がリリースされた後、次のテストコード名に自動的に追従することはありません。

あるリリースがStableのセキュリティリポジトリと同等であると想定しないでくださいtesting-security。Debianの現在のForkyページには、「テスト版のセキュリティアップデートはまだセキュリティチームによって管理されておらず、タイムリーにリリースされない可能性があります。作業を進める前に、最新のテスト版リリース情報を確認してください。」と記載されています。

6. APTはどのような変更を提案していますか？

パッケージインデックスを更新し、候補バージョンを検査してから、ディストリビューションのアップグレードをシミュレートします。

sudo apt update
apt-cache policy
apt-get -s full-upgrade

この-sオプションはトランザクションをシミュレートするだけで、提案されたパッケージをインストールするわけではありません。パッケージの削除、新規インストールされたライブラリ、保留中のパッケージ、候補がないパッケージなど、完全なプランを確認してください。APTはfull-upgrade依存関係を満たすためにパッケージをインストールまたは削除することが許可されているため、「コマンドが完了した」ということは「必要なアプリケーションがすべてインストールされたままになっている」という意味ではありません。

複雑な計画の場合は、リゾルバ診断を使用してシミュレーションを繰り返してください。

apt-get -s -o Debug::pkgProblemResolver=yes full-upgrade

プランによってデスクトップ環境、ディスプレイマネージャ、ネットワーク、ブートローダー、または依存している他のパッケージが削除され、その理由が説明できない場合は、先に進まないでください。ライブラリの移行により、テスト環境では一時的に一部のアプリケーションが使用できなくなる場合があります。パッケージの組み合わせを強制するよりも、移行を待つか、システムを一時的に安定版のままにしておく方が安全な場合があります。--forceシミュレーションをきれいに見せるために、パッケージを一括削除したり、パッケージを削除したりしないでください。

7. 実際のアップグレードはいつ実行すべきですか？

シミュレーションされた計画が許容範囲内であり、バックアップが利用可能で、コンピュータの電源とネットワーク接続が安定していることを確認してから先に進んでください。アプリケーションを閉じ、不安定なリモートセッションではなくローカル端末を使用し、自動確認なしでアップグレードを開始してください。

sudo apt full-upgrade

承認する前に、パッケージと削除の概要をもう一度確認してください。APT が重要なデスクトップ パッケージまたはコア パッケージの削除を提案する場合は、「いいえ」を選択して調査してください。アップグレードが依存関係エラーで停止した場合は、正確なエラー出力を保存してください。すぐに実行しapt --fix-broken installたり、操作を繰り返したりしないでください-y。まず、どのパッケージまたはリポジトリの制約がソルバーの停止を引き起こしたかを特定してください。

トランザクションが正常に完了したら、パッケージの通知に従い、コンピュータを再起動し、グラフィカルセッション、ネットワーク、サウンド、ストレージ、および重要なアプリケーションが正常に動作することを確認してください。大規模な移行が進行中の場合、またはパッケージが一時的に Testing から消えている場合は、Unstable パッケージを混在させるよりも、アーカイブの移行を待つ方が望ましい場合がよくあります。Debian管理者ハンドブックの Debian の APT の章では、通常のアップグレードと の違いfull-upgrade、およびパッケージを削除する機能について説明しています。

8. 移行を検証し、復旧可能な状態を維持するにはどうすればよいでしょうか？

再起動後、アクティブなリリースを確認し、パッケージの一貫性をチェックしてください。

cat /etc/os-release
sudo apt-get check
sudo dpkg --audit
apt-cache policy bash libc6 systemd

変更内容を理解する必要がある場合は、 APT の履歴/var/log/apt/history.logとパッケージのログを確認してください/var/log/dpkg.log。Morgan が依存するアプリケーション（移行のきっかけとなったプロジェクトを含む）をテストしてください。ソースファイルが意図したスイートを指していること、および無効になっていたサードパーティのエントリが密かに復活していないことを確認してください。

デスクトップが通常の作業タスクを完了し、少なくとも1回以上のパッケージ更新が完了するまで、バックアップを保持してください。APTは、TestingからStableへの汎用的なダウングレードをサポートしていません。システムが使用不能になった場合は、システム全体のイメージを復元するか、Stableを再インストールしてデータを復元する方が、すべてのパッケージバージョンを手動で元に戻そうとするよりも、通常は予測可能です。

継続的に使用するには、定期的にアップデートを行い、削除予定のパッケージを確認し、Debianのテストおよびセキュリティに関する通知を常に監視してください。Morganの優先順位が新しい開発パッケージから予測可能なセキュリティメンテナンスに変更された場合、適切な次のステップは、安易なスイート編集やダウングレードでうまくいくという思い込みではなく、クリーンなStableのインストールまたは復元です。

公式資料

• Debian Testingのリリース情報― 現在のコードネームとセキュリティステータス。
• Debian Testingの仕組み― パッケージ移行の基準。
• DebianセキュリティチームFAQ - テストにおけるセキュリティの取り扱い。
• Debian 12 Bookworm リリースノート— サポート対象のアップグレード準備。
• Debian リファレンス: パッケージ管理、およびDebian 管理者ハンドブック: APT。
• APT/apt-get マニュアル— シミュレーションとアップグレード動作。