メニュー

【CentOS Stream 9】dnf updateでlibavif / svt-av1-libsのパッケージ競合エラーが出た時の対処法

  • 投稿日
  • 著者 ひがし
  • カテゴリー インフラ
免責事項・執筆経緯

本記事は、筆者との対話ログに基づきLLM(Gemini)が全構成・本文を直接執筆した技術レポートです。
実際に発生したエラーログの解析から、原因特定・解決手順の提示・運用上の注意点までをGeminiが整理してまとめています。

CentOS Stream 9 サーバーにおいて、sudo dnf update を実行した際に libavif や svt-av1-libs 周りのパッケージ依存関係エラー（Conflict）が発生し、システム更新が停止する問題が発生しました。

本記事では、このトラブルが発生する背景と、安全かつ迅速に解決するための手順をわかりやすく解説します。

発生したエラーログ

dnf update 実行時に出力されたエラー情報は以下の通りです。

問題 1: package gd3php-2.3.3-9.el9.remi.x86_64 from @System requires libavif.so.15()(64bit), but none of the providers can be installed
 - cannot install both libavif-1.1.1-2.el9.next.x86_64 from epel-next and libavif-0.11.1-5.el9.x86_64 from @System
 - cannot install both libavif-1.1.1-2.el9.next.x86_64 from epel-next and libavif-0.11.1-5.el9.x86_64 from epel
 - パッケージの最良アップデート候補をインストールできません libavif-0.11.1-5.el9.x86_64
 - パッケージの最良アップデート候補をインストールできません gd3php-2.3.3-9.el9.remi.x86_64
 - nothing provides libdav1d.so.6()(64bit) needed by libavif-0.11.1-0.x86_64 from remi-safe
問題 2: package php-gd-8.3.35-1.module_php.8.3.el9.remi.x86_64 from remi-modular requires libgd.so.103()(64bit), but none of the providers can be installed
 - cannot install both svt-av1-libs-2.3.0-2.el9.next.x86_64 from epel-next and svt-av1-libs-0.9.0-1.el9.x86_64 from @System
 - cannot install both svt-av1-libs-2.3.0-2.el9.next.x86_64 from epel-next and svt-av1-libs-0.9.0-1.el9.x86_64 from epel

PHPの画像処理拡張（php-gd や gd3php）が依存する各種AV1用ライブラリ（libavif や svt-av1-libs）でバージョン不一致が起きていることが確認できます。

原因解析：epel-next と Remi の不整合

この現象の根本原因は、epel-next リポジトリ と Remi リポジトリ のリリースサイクルのズレにあります。

  • EPEL: RHEL（およびその互換OS）向けの標準サードパーティリポジトリ。
  • epel-next: CentOS Streamのような先行リリース開発OS向けに、最新パッケージをいち早く提供するリポジトリ。
  • Remi: 最新のPHP環境を提供するリポジトリ。標準の EPEL のパッケージ構造を基準にビルドされている。

CentOS Stream 9で epel-next が有効化されていると、libavif などのライブラリのみが先行してアップデートされます。その結果、通常の EPEL を前提に作られている Remi 側のPHPパッケージが必要とするライブラリバージョンと食い違いが生じ、DNFが整合性を取れなくなってアップデートが失敗します。

解決手順

1. 一時的に epel-next を除外して更新を試す

まず、epel-next を無効化した状態で更新コマンドを実行します。

sudo dnf update --disablerepo=epel-next

これでエラーなく更新が完了する場合、原因が epel-next との不整合であったことが明確になります。

2. epel-next を恒久的に無効化する

毎回コマンドラインに指定するのは手間となるため、リポジトリの設定自体を無効化しておきます。

sudo dnf config-manager --set-disabled epel-next

これで次回以降は、通常の sudo dnf update だけでスムーズに更新が通るようになります。

Q. epel-next を無効化しても問題ないか？

結論：一般的なWebサーバー・開発環境であれば無効化して全く問題ありません。

  1. 必要な追加パッケージのほぼ全ては通常の EPEL から取得可能です。
  2. epel-next は先取り要素が強いリポジトリであるため、無効化しておく方がRemiなどのサードパーティリポジトリとの競合を防ぎ、システムをより安定して運用できます。

まとめ

CentOS Stream 9環境でRemiリポジトリ（PHP環境など）を利用中に dnf update でパッケージ競合が発生した場合は、epel-next リポジトリを無効化するのが最も確実で安全な解決策です。