Debian系で apt upgrade を実行すると、更新候補があるのにパッケージが保留されることがある。この表示だけでは、依存関係の変更、明示的な hold 、版選択の優先度、段階的配布のどれが原因かは分からない。
保留は、パッケージに一つの異常状態が設定されたことを意味しない。現在の候補版と依存関係に対して、実行したコマンドの変更許容範囲では採用できない更新計画が残ったことを示す。対応の起点は、保留を強制解除することではなく、通常更新と完全更新が提案する差分を比較することである。
本稿では、パッケージ更新の運用を前提に、保留されたパッケージを安全に切り分ける手順を示す。対象は Debian 系の APT であり、 Ubuntu 固有の段階的配布は別の分岐として扱う。
保留は更新計画が選ばれなかった結果である
APT は、インストール済み版、取得可能な版、優先度、依存関係、競合関係、 hold を材料に、適用する変更一式を計算する。更新候補が存在しても、実行したコマンドが許可しない削除を必要とする場合、そのパッケージは現在の版に残る。
apt upgrade は、依存関係を満たすための新規パッケージを追加できるが、インストール済みパッケージは削除しない。更新に削除が必要なら、その更新を実行しない[1]。一方、 apt full-upgrade は、システム全体の更新に必要であれば、インストール済みパッケージの削除を更新計画へ含める[1]。
同じ upgrade という名前でも、 apt-get upgrade は新規パッケージの追加も既存パッケージの削除も行わない。新しい依存パッケージの追加だけを許可する場合は、 apt-get upgrade に –with-new-pkgs を付ける[2]。 apt upgrade と apt-get upgrade を同じ挙動として説明すると、保留理由の判断を誤る。
| 操作 | 新規パッケージの追加 | 既存パッケージの削除 | 主な用途 |
|---|---|---|---|
| apt upgrade | 依存関係に必要なら追加する | 行わない | 対話的な通常更新 |
| apt-get upgrade | 既定では行わない | 行わない | 変更範囲を狭く固定した更新 |
| apt-get upgrade –with-new-pkgs | 依存関係に必要なら追加する | 行わない | 削除を許可せず新規依存だけを受け入れる更新 |
| apt full-upgrade | 追加する | 必要なら行う | 依存関係の変更を含む更新 |
保留という表示だけから、 full-upgrade を実行すべきだとは決められない。削除対象が旧カーネルや置換済みパッケージなら妥当な場合がある一方、業務で使うサービスや外部リポジトリのパッケージが削除候補なら、リポジトリ構成や優先度を先に直す必要がある。
最初に候補版と二つの更新計画を確認する
切り分けでは、パッケージ一覧を更新した後、保留名、 hold 、候補版、通常更新と完全更新の差を同じ時点の情報で確認する。 apt-get のシミュレーションはシステムを変更せず、インストールと削除の予定を表示する[2]。
1 2 3 4 5 6 | sudo apt update apt list --upgradable apt-mark showhold apt-cache policy PACKAGE sudo apt-get --simulate upgrade sudo apt-get --simulate dist-upgrade |
apt update は、設定済みの取得元からパッケージ索引を更新する。古い索引のまま調べると、すでに解消した依存関係や候補版を見て判断することになる[2]。
apt-cache policy PACKAGE は、インストール済み版、候補版、利用可能な版と優先度を確認するために使う。複数のリリースや外部リポジトリが混在する環境では、依存関係を調べる前に、意図した取得元の版が候補になっているかを確認する[3][4]。
通常更新と完全更新のシミュレーションを比較すると、保留を解消するために何が追加または削除されるかが分かる。差分のうち、特に Remv と表示される削除予定、別系列から入る版、主要サービスの置換を確認する。削除件数だけで安全性を判断せず、削除されるパッケージの役割を見る。
明示的な hold は更新計画の保留と分ける
apt-mark hold は、対象パッケージが自動的にインストール、更新、削除されることを防ぐ。 apt-mark showhold は、現在 hold されているパッケージを一覧表示する[5]。
hold が存在する場合、保留は依存関係の一時的な結果ではなく、管理者が保存した状態に起因する。解除前に、誰が、何の障害を避けるために、どの版へ固定したかを確認する。理由が残っているなら、更新を通すためだけに解除してはならない。
意図しない hold であることを確認した場合に限り、解除して更新計画を再計算する。
1 2 | sudo apt-mark unhold PACKAGE sudo apt-get --simulate dist-upgrade |
hold を解除しただけでは、安全な更新になったとは限らない。解除後のシミュレーションで、追加、削除、版の切り替えを再確認する必要がある。
候補版が意図と異なる場合は取得元と優先度を直す
複数の Debian リリース、 backports 、ベンダー提供元、独自リポジトリを併用すると、複数の版が候補になり得る。 APT は版ごとの優先度と依存関係に基づいて候補を選び、/etc/apt/preferences と /etc/apt/preferences.d/ の設定は既定の優先度を上書きする[4]。
apt-cache policy PACKAGE で、候補版が意図したリリースや取得元から選ばれていない場合、個別パッケージを強制更新する前に sources.list 、 sources.list.d 、 pinning を確認する。依存先だけが別系列へ移る計画は、当該パッケージの更新を通しても、次回以降の更新で同じ不整合を再発させる。
必要な依存版が取得できない場合も、保留は起こり得る。ミラー同期の途中なら時間経過で解消するが、取得元の混在や署名・配布設定の誤りなら待っても解消しない。再試行を対応策にする前に、候補版と取得元が一貫しているかを確認する。
段階的配布は Ubuntu の分岐として確認する
APT は、パッケージのメタデータに Phased-Update-Percentage がある場合、パッケージ名、版、マシン識別子から配布対象を判定し、対象外の版へ低い優先度を与える仕組みを持つ[4]。 Ubuntu はこの仕組みを安定版更新の段階的配布に使用しており、対象外の端末では一時的にパッケージが保留される[6]。
Ubuntu で段階的配布が疑われる場合は、 apt policy PACKAGE の版一覧に表示される phased の割合を確認する。段階的配布だけが理由なら、通常は待つことで対象へ入る。 Ubuntu の運用資料では、セキュリティ更新は段階的配布の対象外とされている[6]。
段階的配布を無効化したり、 apt install PACKAGE で先行適用したりすることは可能だが、保留理由を確認せずに行うべきではない。同じ表示でも、実際には削除を必要とする依存変更やリポジトリ混在が原因の場合がある。 Debian 環境で保留が出たという理由だけで、 Ubuntu の段階的配布を原因とみなすこともできない。
実行する操作はシミュレーション結果から選ぶ
新規依存の追加だけで更新できる場合
apt upgrade は必要な新規依存を追加できるため、索引更新後に再実行する。 apt-get upgrade を運用コマンドにしている場合は、–with-new-pkgs を付けたシミュレーションで差分を確認してから適用する。
1 2 | sudo apt-get --simulate upgrade --with-new-pkgs sudo apt-get upgrade --with-new-pkgs |
既存パッケージの削除が必要な場合
dist-upgrade のシミュレーションで削除が提示された場合、削除対象が置換されるパッケージか、必要な機能を失うパッケージかを確認する。許容できる計画であることを確認した後に、 apt full-upgrade を実行する。
1 | sudo apt full-upgrade |
full-upgrade は保留を消すための強制操作ではない。削除を含む更新計画を承認する操作である。提案内容を読まずに定期ジョブへ組み込むと、保留を避ける代わりに意図しない削除を自動化する。
個別パッケージだけを更新する場合
対象を限定する場合も、最初に個別更新をシミュレーションする。依存関係の解決によって、指定していないパッケージの追加や削除が提案される可能性がある。
1 2 | sudo apt-get --simulate install --only-upgrade PACKAGE sudo apt install --only-upgrade PACKAGE |
個別更新は、更新対象を絞る操作であり、依存関係を無視する操作ではない。シミュレーションが意図しない削除や別系列への移行を示す場合は、個別更新を中止して取得元と優先度を修正する。
運用では保留件数ではなく未処理理由を記録する
保留を監視する場合、件数だけを異常判定に使うと、明示的な hold 、段階的配布、依存変更を区別できない。通知には、パッケージ名、インストール済み版、候補版、 hold の有無、通常更新と完全更新の差分を含める。
同じパッケージが連続して保留された場合は、時間経過だけで解消する条件かを再評価する。候補版が変わらないまま削除要求が続くなら、定例メンテナンスで full-upgrade の可否を判断する。候補版や取得元が揺れているなら、リポジトリ構成の問題として扱う。
セキュリティ上の優先度は、保留という表示ではなく、対象版に修正が含まれるかによって判断する。保留された全パッケージを緊急扱いする必要はないが、重要な修正を含む更新を「保留だから安全側」として放置することもできない。
保留を解消する前に更新計画を読み取る
apt upgrade の保留は、更新が存在しないことでも、 APT が壊れたことでもない。現在の候補版と依存関係に対して、そのコマンドが許可する追加と削除の範囲では採用されなかった更新があることを示す。
判断手順は、索引を更新し、 hold を確認し、候補版と取得元を確認し、通常更新と完全更新のシミュレーションを比較することである。新規依存だけなら通常更新の範囲で進め、削除が必要なら削除対象を承認した上で full-upgrade を選ぶ。候補版が意図と異なるなら、パッケージを強制するのではなく取得元と優先度を修正する。
保留を消すこと自体を目的にすると、更新理由と削除理由が見えなくなる。運用上の目的は、保留件数をゼロにすることではなく、未適用の更新が残った理由を説明でき、採用または見送りを再現可能な手順で決められることである。
参考文献
- APT Project, “apt(8),” Debian Manpages: Debian trixie, 2025. https://manpages.debian.org/trixie/apt/apt.8.en.html
- APT Project, “apt-get(8),” Debian Manpages: Debian trixie, 2025. https://manpages.debian.org/trixie/apt/apt-get.8.en.html
- APT Project, “apt-cache(8),” Debian Manpages: Debian trixie, 2025. https://manpages.debian.org/trixie/apt/apt-cache.8.en.html
- APT Project, “apt_preferences(5),” Debian Manpages: Debian trixie, 2025. https://manpages.debian.org/trixie/apt/apt_preferences.5.en.html
- APT Project, “apt-mark(8),” Debian Manpages: Debian trixie, 2025. https://manpages.debian.org/trixie/apt/apt-mark.8.en.html
- Canonical, “About apt upgrade and phased updates,” Ubuntu Server documentation, 2025. https://documentation.ubuntu.com/server/explanation/software/about-apt-upgrade-and-phased-updates/