DNF5移行でシェルスクリプトの挙動が変わる箇所を事前に洗い出す｜Fedora本番への適用と切り戻し

DNF5移行がシェルスクリプトに影響する理由

Fedora 41からパッケージ管理ツールのデフォルトがDNF4からDNF5に切り替わりました。表面上はdnf installなどの基本コマンドが継続して動作しますが、内部実装はPythonからC++に刷新されており、コマンド出力のフォーマット・終了コードの扱い・プラグイン機構が一部変わっています。

手動操作では気づきにくい差異も、シェルスクリプトの中でDNF出力をパースしていたり、終了コードで処理を分岐させていたりすると、本番環境で予期しない障害につながります。本記事では変更が集中しやすいパターンの整理から、移行前の洗い出し手順、本番への段階的適用、そして切り戻し方法まで一通り解説します。

挙動変化が起きやすい5つのパターン

1. バイナリ名と実行パス

Fedora 41以降、/usr/bin/dnfはシンボリックリンクとしてdnf5を指すようになっています。ハードコードで/usr/bin/dnfを呼び出しているスクリプトは基本的に動作し続けますが、which dnfやcommand -v dnfの出力を条件分岐に使っているケースは、リンク先が変わったことで意図しない動作をする場合があります。dnf4コマンドとの共存環境では特に注意が必要です。

2. コマンド出力のパース

dnf repolist・dnf info・dnf history listなどの出力をgrepやawkでパースしているスクリプトは、DNF5で列幅・列順・ヘッダー文字列が変わるため、既存の正規表現がマッチしなくなる可能性があります。たとえばdnf history listは、DNF5ではトランザクションIDの表示形式や列構成が変わっており、旧パターンで列番号を直接指定しているコードは誤動作します。

3. 終了コードへの依存

dnf check-updateは更新パッケージが存在する場合に終了コード100を返す仕様がDNF4から継続しています。ただし、オプションの組み合わせによっては終了コードの意味が変わるケースが報告されています。$?の値だけで分岐しているスクリプトは、DNF5のリリースノートで期待するコードの意味を確認してから運用するのが安全です。

4. プラグイン依存

DNF4はPythonプラグインAPIを持っており、dnf-plugin-*パッケージで機能を拡張できました。DNF5はC++で再実装されたプラグインシステムを採用しており、既存のPythonプラグインはそのままでは動作しません。スクリプト内でdnf copr・dnf versionlock・dnf repoclosureなどプラグイン由来のサブコマンドを使っている場合、DNF5対応版パッケージが提供されているかどうかを事前に確認する必要があります。

5. 設定ファイルパスの変更

DNF5は/etc/dnf5/dnf5.confを主設定ファイルとして参照します。スクリプト内で/etc/dnf/dnf.confをsedで書き換えたり読み込んだりしている場合、DNF5環境では変更が反映されない可能性があります。--setoptオプションの扱いも一部変わっているため、動的にオプションを注入しているスクリプトは挙動テストが必要です。

本番適用前の洗い出し手順

実際にスクリプトを変更する前に、影響範囲を機械的に洗い出すことが重要です。以下の手順でリポジトリ内のスクリプトを対象に静的チェックをかけます。

ステップ1：DNF関連呼び出し箇所の一覧化

まずリポジトリ全体からdnfを含むシェルスクリプトを洗い出します。

grep -rn '\bdnf\b' /path/to/scripts/ --include='*.sh' -l

続いて、パース処理や終了コード分岐が疑われる箇所を絞り込みます。

# 出力パース（grepとの組み合わせ）
grep -rn 'dnf.*|.*grep\|grep.*dnf' /path/to/scripts/ --include='*.sh'

# 終了コード参照
grep -rn 'check-update\|\$?' /path/to/scripts/ --include='*.sh'

# プラグイン系サブコマンド
grep -rn 'dnf.*copr\|dnf.*versionlock\|dnf.*repoclosure' /path/to/scripts/ --include='*.sh'

ステップ2：DNF4とDNF5で出力を並べて差分確認

DNF4がまだ使える環境（Fedora 40以前、またはdnf4パッケージを明示インストールした環境）があれば、同一コマンドを両バージョンで実行して出力を比較します。コンテナを使う場合、Fedora 40ベースのイメージとFedora 42ベースのイメージを用意して並行実行すると差分が明確になります。

# DNF4環境（別ホストまたはコンテナ）で実行
dnf4 history list > /tmp/dnf4_history.txt

# DNF5環境で実行
dnf5 history list > /tmp/dnf5_history.txt

diff /tmp/dnf4_history.txt /tmp/dnf5_history.txt

ステップ3：shellcheckとトレース実行

shellcheckはDNF5固有の問題は検出しませんが、$?の取り回しや変数引用ミスなど、DNF移行で露呈しやすいスクリプトの弱点をあぶり出せます。DNF5が動くステージング環境でスクリプトを実際に流し、set -xでトレースログを取ることで予期しない分岐を可視化します。

shellcheck /path/to/scripts/*.sh

# ステージング上でトレース実行
bash -x /path/to/scripts/update.sh 2>&1 | tee /tmp/trace_update.log

Fedora本番環境への段階的適用

洗い出した問題を修正したスクリプトを本番に適用する際は、一括更新ではなく段階的に進めます。

• ステージングで全スクリプトを通し実行する：本番と同等の構成でテストし、エラーがないことを確認します。
• canaryホストへの先行適用：本番クラスターの1台のみFedora新版に更新し、スクリプトを監視付きで動かします。問題が出なければ残りのホストへ順次適用します。
• 適用後のログ監視：journalctl -u <サービス名> -fでDNF関連のエラーが出ていないかリアルタイムで確認します。dnf5 history listでトランザクション履歴に異常がないかも確認します。

スクリプトの変更と本番適用を同時に行わないことが基本です。スクリプトをDNF4・DNF5両対応にしてから先にリリースし、その後でOSのアップグレードを実施するという順序が、切り戻し時のコストを最小化します。

切り戻し手順と判断基準

本番適用後に問題が発生した場合の切り戻し方法は、影響範囲によって大きく3段階に分かれます。

スクリプトのみ切り戻す

スクリプト自体に問題がある場合、gitでリビジョンを戻すのが最速です。dnf5コマンドは残したままスクリプトだけを旧バージョンに戻し、動作を確認します。

git revert HEAD

# または特定ファイルのみ戻す場合
git checkout <commit-hash> -- scripts/update.sh

dnf4を並行インストールして一時退避

DNF5に起因する動作変更が確定し、スクリプト側の修正が間に合わない場合、dnf4パッケージを明示インストールして一時的にDNF4を使う選択肢があります。Fedora 41・42ではdnf4パッケージがリポジトリに存在しており、インストール後にスクリプト内のコマンドをdnf4に切り替えることで旧挙動に近づけられます。

dnf install dnf4

# 切り戻し確認
dnf4 check-update
dnf4 history list

ただしこの方法はあくまで一時的な退避です。DNF4はDNF5への移行が完了次第リポジトリからの提供終了が予定されているため、スクリプト側の対応を並行して進めることが前提になります。

OSレベルでFedora旧版に戻す

スナップショット（仮想マシンやBtrfsスナップショット）を事前に取得していれば、ロールバックが最も確実です。物理サーバーで事前スナップショットがない場合は切り戻しコストが高くなるため、canary段階で問題を検出することが重要です。本番適用前にスナップショットを取ることを手順書に組み込んでおく運用が一般的です。

2026年現行環境での補足

2026年時点でリリースされているFedora 43・44はDNF5がデフォルトであり、dnfコマンドはdnf5へのシンボリックリンクとして提供されています。dnf4互換パッケージは引き続きリポジトリに存在していますが、将来的には削除されることがFedoraの方針として示されています。

RHEL・AlmaLinux・Rocky Linuxの系統はDNF4ベースで安定しており、2026年時点でDNF5への完全移行は行われていません。Fedora由来のスクリプトをRHEL系に流用している場合、逆方向の互換性問題（DNF5専用オプションをDNF4で実行しようとする状況）が起きることがあります。スクリプト内でディストリを判定してコマンドを切り替える分岐を持っておくと、両環境への対応が楽になります。

DNF5の一部サブコマンドでは--jsonオプションが機能しており、grep・awkによるテキストパースをJSONパースに置き換えることでフォーマット変更への耐性を高められます。jqが使える環境では、出力パース部分のリファクタリングを中長期の改善として検討する価値があります。