パッケージを更新する前に何が変わるかを確かめる手順

なぜ更新を適用する前に確認が必要か

パッケージ管理ツールはコマンド一つで複数のパッケージをまとめて更新できる便利なツールですが、確認なしに適用すると予期せぬ問題が起きることがあります。たとえば、依存関係の解消のために既存パッケージが削除・置換される、設定ファイルの書式が変わってサービスが起動しなくなる、共有ライブラリの更新でプロセスの再起動が必要になるといったケースです。

「更新するかどうか」を判断するためには、まず「何がどのように変わるか」を把握する必要があります。この記事では、更新の実行前に行う確認の流れを説明します。コマンドのオプション解説ではなく、確認・判断・適用という作業の流れに絞っています。

更新対象のパッケージを一覧で把握する

最初に、現在の環境で更新可能なパッケージの一覧を取得します。

Debian/Ubuntu 系の場合は次のコマンドで確認できます。

apt list --upgradable

RHEL/Rocky Linux/AlmaLinux 系（dnf）の場合はこちらです。

dnf check-update

一覧を確認するときに意識したいのは、パッケージの種別による影響度の違いです。カーネル（kernel、linux-image）は更新後に再起動が必要になるため、再起動できるタイミングを別途計画する必要があります。glibc や libssl などの共有ライブラリはほぼすべてのプログラムが依存しており、更新後には関連するサービスの再起動が必要になることがあります。nginx や postgresql などのアプリケーションパッケージは影響範囲がそのアプリに限定されますが、設定の互換性は別途確認が必要です。

全件を一度にまとめて更新するのではなく、影響が大きそうなパッケージを先に個別確認する進め方が安全です。

変更内容（チェンジログ）で影響を読み取る

更新対象が絞れたら、各パッケージのチェンジログを確認します。

Debian/Ubuntu 系では次のコマンドを使います。

apt changelog パッケージ名

RHEL/Rocky Linux/AlmaLinux 系では dnf updateinfo で確認できます。

dnf updateinfo info パッケージ名

チェンジログを読む際に着目するポイントは次のとおりです。

変更の種別を把握する
セキュリティ修正・バグ修正・機能追加の3つに分けて読むと整理しやすくなります。CVE番号が記載されているセキュリティ修正は、対象の脆弱性が公開されている場合、優先的に適用を検討します。

バージョン番号の変化に注目する
メジャーバージョン（1.x → 2.x）の変更は、設定の互換性が失われている可能性があります。パッチバージョン（1.2.3 → 1.2.4）の変更は後方互換性が保たれていることが多いですが、必ずしも保証されるわけではないため確認は欠かせません。

「Breaking Change」の記述を探す
チェンジログに “breaking change” や “incompatible with previous versions” といった記述がある場合、更新後に設定変更が必要になる可能性があります。この記述を見落とすと、更新後にサービスが起動しない原因になります。

ドライランで依存関係の変化を確かめる

個別パッケージの確認が終わったら、ドライランを実行して「適用するとしたら何が変わるか」を一括で確かめます。ドライランとは、実際には何も変更せずに更新後の状態をシミュレートして表示する機能です。

Debian/Ubuntu 系の場合はこちらです。

apt-get -s upgrade

RHEL 系の場合はこちらです。

dnf upgrade --assumeno

ドライランの出力で確認したい点は次のとおりです。

• Removing（削除）の行に重要なパッケージが含まれていないか：依存関係の解決のために、想定外のパッケージが削除されることがあります。
• 想定外のパッケージが新たに追加されていないか：依存関係の更新に伴い、不要なパッケージが自動インストールされる場合があります。
• 変更対象の件数が予想より多くないか：「1件だけ更新するつもりが30件に影響する」という状況は、依存関係が複雑になっているサインです。

ドライランの出力で削除対象のパッケージが多い場合や、依存関係が複雑に変化している場合は、一度立ち止まって内容を精査することをおすすめします。

更新を適用するかどうかの判断

確認した内容をもとに、即日適用するか、時期を検討するかを判断します。

即日適用を優先しやすいケースは、CVEが修正されているセキュリティ更新で対象の脆弱性が公開済みの場合、またはバグ修正のみで破壊的変更の記述がない場合です。一方、メジャーバージョンアップや依存関係の大きな変更を伴う場合、カーネルや共有ライブラリが対象で再起動・サービス再起動が必要になる場合、ドライランで想定外の削除・追加が発生している場合は、慎重に進める必要があります。

セキュリティ更新に絞って適用したい場合は、RHEL 系では次のオプションが使えます。

dnf upgrade --security

特定のパッケージだけを対象にして更新を適用することもできます。Debian 系では apt-get install –only-upgrade、RHEL 系では dnf upgrade にパッケージ名を指定します。全体更新ではなく対象を絞ることで、ドライランで確認した範囲だけを変更できます。

よくあるつまずきと注意点

カーネル更新は再起動するまで反映されない
カーネルが更新されても、再起動しなければ現在のカーネルが動き続けます。更新後はいつ再起動を行うかを計画的に決める必要があります。現在動作中のカーネルと最新のインストール済みカーネルは次のコマンドで確認できます。

# RHEL 系
uname -r
rpm -q kernel | sort

# Debian 系
uname -r
dpkg -l linux-image-* | grep ^ii

apt upgrade と apt full-upgrade の違いに注意する
apt upgrade は依存解決のためにパッケージを削除しません。apt full-upgrade（旧称 dist-upgrade）は依存解決のために既存パッケージを削除することがあります。サーバー環境で full-upgrade を実行する際は、必ずドライランで事前確認を行ってください。

共有ライブラリ更新後はサービスの再起動が必要
libssl などの共有ライブラリが更新された場合、そのライブラリを使っているプロセスは古いバージョンをメモリ上に保持したままになります。Debian 系では needrestart コマンドを使って再起動が必要なサービスを確認できます。

needrestart -l

再起動が必要なプロセスの一覧が表示されるので、サービス停止の影響を考慮したうえで順次再起動を行います。

dnf の autoremove は別途確認してから実行する
dnf upgrade の後に autoremove を実行すると、依存関係がなくなったパッケージが削除されます。何が削除されるかを先に確認するには次のコマンドが使えます。削除対象を把握してから実行するかどうかを判断してください。

dnf autoremove --assumeno