ガイド

著者 Matt Connor 2026-08-21

RockyとAlmaでEPEL・CRBを追加する方法

Q: Rocky Linux 9 または AlmaLinux 9 で EPEL を有効にするにはどうすればよいですか？

まず sudo dnf install -y dnf-plugins-core、次に sudo dnf config-manager --set-enabled crb、その後 sudo dnf install -y epel-release を実行します。dnf repolist --enabled で確認すると、baseos、appstream、extras、crb、epel が表示されるはずです。EPEL パッケージをインストールする前に CRB を有効にしてください。多くのパッケージが CRB でのみ提供されるライブラリに依存しているためです。バージョン 8 では、リポジトリー ID は crb ではなく powertools です。

Q: dnf で no such command: config-manager と表示されるのはなぜですか？

config-manager は組み込みコマンドではなく dnf プラグインだからです。minimal イメージやコンテナイメージには、dnf-plugins-core が含まれていません。メッセージ自体に対処方法が示されています。シェルが括弧を解釈しないように引用符で囲んだ sudo dnf install -y 'dnf-command(config-manager)' を実行してください。まだ何もインストールできない場合は grep -rl crb /etc/yum.repos.d/ を実行し、表示されたファイルを開いて、[crb] セクションの enabled=1 を手動で設定します。

Q: CRB と PowerTools の違いは何ですか？

同じリポジトリーを異なる名前で呼んでいます。バージョン 8 では PowerTools と呼び、ID は powertools です。バージョン 9 以降では CRB と呼び、ID は crb です。Red Hat の製品では、このコンテンツを CodeReady Linux Builder と呼びます。開発用ヘッダー、静的ライブラリ、ビルド時ツールを提供し、Rocky および AlmaLinux 9 ではデフォルトで無効になっています。AlmaLinux 10 では 10.0 からデフォルトで有効になっているため、そこで有効化コマンドを実行する前に dnf repolist --enabled を確認してください。

Q: 既存の構成を壊さずに EPEL を削除するにはどうすればよいですか？

まず dnf repository-packages epel list installed でインベントリを確認してください。epel-release パッケージだけを削除しても、EPEL からインストールしたパッケージは削除されないためです。それらのパッケージはディスク上に残り、更新元を失います。また、エラーが表示されないままセキュリティ修正も受け取れなくなります。パッケージごとに判断し、不要になったものを削除または置き換えてから sudo dnf remove epel-release を実行してください。EPEL のパッケージが別のパッケージを置き換えておらず、単純に削除する必要がある場合は、sudo dnf repository-packages epel remove で一度のトランザクションでセット全体を削除できます。実行を確定する前に、提案された一覧を慎重に確認してください。

Rocky LinuxとAlmaLinuxでdnfがパッケージを見つけられない理由を解説します。BaseOS、AppStream、CRBの違い、EPELの安全な追加方法、リポジトリを整理する手順が分かります。

dnf が目的のパッケージを見つけられない理由

EPEL と CRB は、新規の Rocky Linux または AlmaLinux サーバーでは最初から提供されない 2 つのリポジトリです。そのため、新しいサーバーで dnf install htop を実行すると、No match for argument: htop が表示され、その後 Error: Unable to find a match: htop になります。異常が発生しているわけでも、ミラーが停止しているわけでもありません。ベースディストリビューションが意図的に提供するパッケージを少数に絞っており、CRB は存在するものの無効化されています。また、EPEL は別のコミュニティリポジトリであり、自分で追加する必要があります。

Ubuntu では同じパッケージが universe にあり、universe はほぼすべてのクラウドイメージで有効になっているため、この問題はほとんど起こりません。Red Hat 系ではパッケージの分割方法が異なり、標準で有効な範囲も狭くなっています。解決方法は 3 つのコマンドを実行することです。このガイドの後半では、最初の 1 週間では誰も教えてくれない点を説明します。これらのリポジトリが提供するものと提供しないもの、そしてサードパーティーリポジトリによってベースシステムが知らないうちに置き換えられるのを防ぐ方法です。

これらのコマンドの確認方法。コマンドのテスト用コンテナは Ubuntu のみで実行しているため、以下の dnf コマンドはテスト環境で実行していません。Rocky Linux と AlmaLinux のドキュメントに従っています。各手順には表示されるはずの出力を記載しているため、ブロック全体を一度に貼り付けず、自分のサーバーで各手順を確認してください。

BaseOS、AppStream、CRBとは何ですか？

BaseOS はオペレーティングシステムそのものです。kernel、glibc、systemd、主要な userland が含まれます。ここで提供されるバージョンは、メジャーリリースのサポート期間中は固定されます。セキュリティ修正は、その固定されたバージョンへバックポートされます。BaseOS で数年前に見えるバージョン番号が付いていても、未修正のパッケージという意味ではありません。修正済みの古いバージョンです。これがエンタープライズディストリビューションの基本的な考え方です。

AppStream には、その上で実行するソフトウェアが含まれます。Web サーバー、データベース、言語ランタイム、エディター、監視エージェントなどです。version 8 では、AppStream の多くが代替ストリームを持つ modules として提供されていたため、dnf module list が重要でした。たとえば、PHP のストリームを1つ選択していました。Version 9 ではモジュール方式がほぼ廃止されたため、Rocky 9 と Alma 9 では通常、各ソフトウェアのバージョンは1つだけ提供され、先に有効化する module もありません。

Extras はデフォルトで有効になっており、規模も小さい repository です。主に他の repository 用の release package を提供します。epel-release 自体もここから提供されます。このため、Rocky や Alma に EPEL をインストールする際、出所不明の URL を信頼する必要はありません。

CRB は CodeReady Builder repository です。version 8 では PowerTools と呼ばれていました。ディストリビューションのビルド側を担い、development header、static library、パッケージのビルド時に必要なテストおよびドキュメント用のツールを提供します。CRB はすでに mirror 上にありますが、デフォルトでは無効です。Red Hat の製品では同じ内容を CodeReady Linux Builder と呼びます。これは subscription に含まれますが、Red Hat はサポート対象外としています。Rocky と Alma は、内容と無効化されたデフォルト設定の両方を引き継いでいます。

Debian や Ubuntu から移行してきた読者向けに説明すると、main は runtime package と -dev header を1つの archive にまとめています。そのため、そこでは CRB を有効にする必要がありません。EPEL に最も近いものは universe です。これはコミュニティーによって保守されており、ベンダーによるサポート保証はありません。

EPEL とは何か、誰が支えているのか

EPEL は Extra Packages for Enterprise Linux の略です。Fedora のプロジェクトであり、Fedora に存在するパッケージを現在のエンタープライズリリース向けに再ビルドし、主に Fedora コミュニティのボランティアで構成される EPEL Special Interest Group が保守しています。Red Hat はビルドおよびミラーのインフラストラクチャをホストし、Red Hat のエンジニアが一部のパッケージを保守しています。関係はそこまでです。EPEL は Red Hat の製品ではありません。 EPEL パッケージには、RHEL 上でも再構築版上でも、サポート契約や SLA (service level agreement) は付帯しません。

EPEL を安全に有効化できる根拠となるポリシーが1つあります。EPEL パッケージは、ベースディストリビューションのパッケージを決して置き換えてはなりません。AppStream が nginx を提供する場合、EPEL は提供しません。このルールは EPEL パッケージをレビューする担当者によって適用されるため、EPEL だけに対する約束です。後から追加するものによる問題を防ぐものではありません。

存続期間に関する保証もベースディストリビューションとは異なります。3年目に問題になりやすいのがこの点です。BaseOS のパッケージバージョンは、メジャーリリースの10年間のライフサイクル全体で固定されます。一方、EPEL のメンテナーが約束する期間は、はるかに短く、少なくとも1つの RHEL マイナーリリースまたは13か月のいずれか短い方です。実際には、ほとんどのパッケージがそれより長く保守されます。ただし、メンテナーが離れると廃止されるものもあります。また、EPEL は Fedora に追従するため、ディストリビューションのライフサイクル途中で新しいメジャーバージョンへ移行するものもあります。そのため、通常の dnf upgrade によって、安定していると思っていたサーバー上の EPEL ツールが新しいメジャーバージョンになることがあります。依存しているパッケージが、通知を受け取ることなく更新されなくなる場合もあります。

有効化する前に知っておくべき別の影響があります。EPEL は、最新の RHEL マイナーリリースを基準にビルドされます。サーバーを古いマイナーリリースのまま維持し、固定したミラーやベンダーのポイントリリースリポジトリを使用している場合、EPEL パッケージが、現在インストールされているものより新しいベースライブラリを要求することがあります。dnf はこれを依存関係の不足として報告します。そのためミラーの問題に見えますが、実際にはバージョンの不整合が原因です。

Rocky または Alma で CRB を有効にして EPEL をインストールする

sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --set-enabled crb
sudo dnf install -y epel-release
sudo dnf makecache
dnf repolist --enabled

dnf repolist --enabled には、baseos、appstream、extras、crb、epel が表示されるはずです。小さな epel-cisco-openh264 エントリが表示される場合もあります。これは epel-release が追加したものです。その一覧に crb がない場合、有効化が反映されていません。理由は次のセクションで説明します。

Rocky 8 と Alma 8 では、このリポジトリは引き続き PowerTools という名前です。そのため、中央のコマンドは sudo dnf config-manager --set-enabled powertools になります。リポジトリ ID では大文字と小文字が区別されます。古い CentOS 8 のドキュメントでは、PowerTools のように大文字を使って表記されていることがありますが、この表記は一致しません。AlmaLinux 10 では、2025 年 9 月の変更により、10.0 以降で CRB リポジトリがデフォルトで有効になっています。そのため、ここでは epel-release の手順だけ実行します。

epel-release は、すでに有効になっている extras から提供されます。そのため、信頼する URL を指定したり、手動で鍵をインポートしたりする必要はありません。このパッケージは /etc/yum.repos.d/epel.repo を書き込み、EPEL の署名鍵を /etc/pki/rpm-gpg/ にインストールします。そのファイルで gpgcheck=1 を確認し、署名エラーを --nogpgcheck で回避するよう指示しているガイドは無視してください。署名の検証に失敗する場合、パッケージが申告どおりのものではないか、システム時刻が正しくありません。

Rocky では、epel-release により /usr/bin/crb に小さなヘルパーもインストールされます。そのため、sudo crb enable と crb status は、プラグインなしで同じ処理を実行します。使用する前に command -v crb でインストール済みか確認してください。すべての再構築版のすべてのブランチに含まれているわけではありません。

EPEL が一覧に載っているだけでなく到達可能であることを確認するには、EPEL だけが提供しているパッケージを検索します。

dnf repoquery --repo=epel htop

パッケージ名、バージョン、アーキテクチャが表示されます。何も表示されない場合、リポジトリは有効ですが、通常は設定の問題ではなく、ミラーまたはメタデータの問題によって何も返していません。次に sudo dnf clean all && sudo dnf makecache を試してください。

dnf で no such command: config-manager と表示される理由

多くの人が最初につまずく箇所です。VPS プロバイダーが提供するイメージでは、特にこの問題が起きます。

No such command: config-manager. Please use /usr/bin/dnf --help
It could be a DNF plugin command, try: "dnf install 'dnf-command(config-manager)'"

config-manager は組み込みの dnf サブコマンドではなく、プラグインです。dnf-plugins-core に含まれています。完全なサーバーインストールではこのパッケージがインストールされますが、最小構成のイメージ、クラウドイメージ、コンテナーイメージでは省かれています。dnf 自身の提案が機能するのは、パッケージがこの仮想機能を宣言しているためです。

sudo dnf install -y 'dnf-command(config-manager)'

そのまま引用してください。括弧はシェル構文なので、引用しないバージョンでは dnf のエラーではなく構文エラーになります。

必要なリポジトリが無効になっているためにプラグインをインストールできない場合は、ファイルを直接編集します。セクションを含むファイルを特定して開き、[crb] の下に enabled=1 を設定します。

grep -rl crb /etc/yum.repos.d/

これは config-manager が書き込む内容とまったく同じです。そのため、手作業で設定しても失われるものはありません。dnf repolist --enabled で結果を確認できます。

一部の EPEL パッケージは、CRB を有効にするまでインストールできません

2 つ目によくある問題では、CRB について一切触れないエラーが表示されます。CRB でのみ提供されるライブラリにリンクする EPEL パッケージは、依存関係の解決時に失敗します。メッセージには、そのライブラリと、それを必要としたパッケージが示されます。

Error:
 Problem: conflicting requests
  - nothing provides libexample.so.0()(64bit) needed by examplepkg-1.4-2.el9.x86_64 from epel

原因は CRB が無効になっているため、dnf がそのライブラリを提供する唯一のリポジトリを参照できないことです。次の 2 点を順番に確認します。

dnf repolist --enabled
dnf --enablerepo=crb repoquery --whatprovides 'libexample.so.0()(64bit)'

通常のインストールがまだ失敗する一方で、2 つ目のコマンドがパッケージ名を表示する場合は、CRB が無効になっています。この種類のエラーは非常に多いため、AlmaLinux は発生を防ぐ目的で version 10 では CRB をデフォルトで有効にしました。--enablerepo=crb は 1 回のインストールで使用する一時的なフラグとしても機能します。ただし、EPEL を使用する場合は CRB を恒久的に有効にしてください。次回の EPEL 更新で、事前の通知なしに新しい CRB 依存関係が追加される可能性があるためです。

このパッケージはどのリポジトリから取得されたか

4 つのリポジトリを有効にして数週間運用すると、確認すべき内容はインストール済みかどうかではなく、どこから取得されたかになります。

dnf repolist --all
dnf info htop
dnf repoquery --installed --qf '%{from_repo} %{name}' | sort | uniq -c | sort -rn
dnf repository-packages epel list installed

インストール済みパッケージに対して dnf info を実行すると、From repo 行が表示されます。dnf list installed では同じ情報が 3 列目に表示され、その前に @ が付きます。そのため、@epel は EPEL からインストールされたことを示し、@System は dnf が取得元を認識していないことを示します。通常は、ダウンロードしたファイルに対して誰かが rpm -i を実行した場合に発生します。repoquery 行にはリポジトリごとのパッケージ数が表示されます。これは、引き継いだサーバーに、存在すら知らなかったリポジトリ由来のパッケージが 40 個あることを見つける最も速い方法です。最後のコマンドでは、あるリポジトリから取得されたパッケージだけを正確に一覧表示できます。その一覧を確認してから、そのリポジトリを削除するか判断します。

apt での習慣に相当するのは apt-cache policy <package> です。最初の 1 か月は、dnf と apt のコマンド対応表を 2 つ目のタブで開いておくと便利です。フラグが異なっていても、概念は対応しているためです。

サードパーティーリポジトリによるベースパッケージの置き換えを防ぐにはどうすればよいですか？

EPEL はこの動作をしないとしています。ほかのリポジトリにはその保証がありません。データベース、エージェント、言語ランタイム用のベンダーリポジトリが、BaseOS でも提供されているライブラリを独自にビルドして配布することがあります。その場合、dnf はそのパッケージをインストールします。dnf のデフォルトのルールは単純で、提供元に関係なく最も高いバージョンを選ぶためです。

主に使用する制御は2つあり、どちらも /etc/yum.repos.d/ 配下のリポジトリファイルに記述します。

priority= は、複数のリポジトリが同じパッケージ名を提供している場合に、どのリポジトリを優先するかを決めます。数値が小さいほど優先され、デフォルトは99です。そのため、ベースリポジトリには小さい値を、サードパーティーリポジトリには大きい値を設定します。これにより、サードパーティー版のほうが新しくても、dnf はベースパッケージを選択します。現在の dnf はこの処理を自動で行うため、CentOS 7 の時代に使われていた個別の yum-plugin-priorities パッケージは、現在は必要ありません。

includepkgs= は、フィルター関連のオプションの中で、より強力なものです。excludepkgs= は、リポジトリから特定のパッケージ名を除外します。ただし、そのリポジトリが提供する可能性のあるパッケージを事前に予測する必要があります。includepkgs= はこの動作を反転させます。このリポジトリが提供できるのは指定した名前のパッケージだけです。独自のエージェントだけを提供するベンダーリポジトリなら、次の1行で設定できます。

[vendor-tools]
name=Vendor tools for EL9
baseurl=https://packages.example.com/el9/x86_64/
enabled=1
gpgcheck=1
gpgkey=https://packages.example.com/RPM-GPG-KEY-vendor
priority=90
includepkgs=vendor-agent,vendor-agent-plugins

バージョン8では、もう1つ知っておくべき設定があります。サードパーティーリポジトリのパッケージは、同じ名前を AppStream モジュールが提供している場合に非表示になることがあります。そのリポジトリのセクションに module_hotfixes=1 を設定すると、dnf はこのフィルタリングを停止します。パッケージが dnf repoquery からは見えているのに、バージョン8のシステムにインストールできない場合は、通常これが原因です。バージョン9ではほぼすべてのモジュールが廃止されたため、この問題はほとんど発生しません。

1つのパッケージを特定のバージョンに固定するには、python3-dnf-plugin-versionlock をインストールして sudo dnf versionlock add <package> を使用します。これは apt-mark hold に相当します。Debian から移行した人が混乱しやすい逆の違いに注意してください。apt では高い Pin-Priority が優先されますが、dnf では低い priority が優先されます。

RHEL 系リポジトリを混在させるとサーバーをアップグレードできなくなる理由

Rocky、Alma、CentOS Stream、Oracle Linux、RHEL は互いにパッケージをインストールできる程度には似ています。一方で、誰もサポートできないシステムになる程度には異なります。

仕組みの原因はバージョン番号です。CentOS Stream 9 は RHEL 9 より先行しているため、Rocky 9 のサーバーを Stream リポジトリに向けると、たとえ一度だけでも、1 パッケージだけでも、Rocky では今後提供されないバージョンのパッケージがインストールされます。次の Rocky マイナーリリースが出たとき、そのパッケージのバージョンは現在のものより低くなるため、dnf upgrade はそれを置き換えません。サーバーは誰もテストしていない組み合わせで動作し、パッチが適用されていると思い込んだまま、何年も気付かずにその状態が続きます。

症状は、dnf upgrade が処理対象なしと報告する一方で、sudo dnf distro-sync が多数のパッケージのダウングレードを提案することです。distro-sync が修復ツールです。有効なリポジトリが実際に提供している内容に、インストール済みのすべてのパッケージを一致させます。ダウングレードも実行します。まず外部リポジトリを無効にしてから実行し、承認する前に提案された一覧を確認してください。古い RPM がミラーに残っていない場合、修復は失敗します。その場合は、依存関係の解決に苦労するより、クリーンなイメージからサーバーを再構築するほうが速く安全です。

ELevate の残骸も、この問題を引き起こす一般的な原因です。ELevate は Leapp を基盤とする AlmaLinux の移行ツールです。CentOS 7 のサーバーを新しいバージョンへ移行したり、再構築ディストリビューション間で変換したりするために使用します。移行を急いで実行すると、EL7 のリポジトリファイルが /etc/yum.repos.d/ に残り、EL7 のパッケージもインストールされたままになります。rpm -qa | grep el7 でそれらを検索できます。該当する各パッケージは、有効なリポジトリから更新できません。後で Leapp を実行すると、対応付けできないパッケージとして報告され、手作業で解消するアップグレードの阻害要因になります。次のメジャーアップグレードが必要になった日に対応するのではなく、サーバーが安定している間に削除してください。

AppStream のパッケージをベンダーリポジトリが上書きするケースは、同じ問題の軽い形です。上記の includepkgs の行が修正方法です。一般的なのはコンテナツールです。Docker 独自のリポジトリにある containerd.io は、AppStream の runc と競合するため、どちらかを削除する必要があります。一度方針を決め、除外設定を記録し、既知の正常な手順に従ってください。Rocky Linux への Docker インストールの手順では、先に削除すべきディストリビューションパッケージを説明しています。

リポジトリに関する apt から dnf への置き換え

/etc/apt/sources.list.d/*.sources は /etc/yum.repos.d/*.repo に相当します。1 つのファイルに複数の [sections] を記述でき、それぞれに固有の id を設定します。
add-apt-repository universe は dnf install epel-release に相当します。ただし、universe は Ubuntu 自身のアーカイブ内にあり、EPEL は独立したプロジェクトです。
apt update に相当するものはありません。dnf は独自のスケジュールでメタデータを更新し、dnf makecache で直ちに更新を強制します。
apt-cache policy <pkg> は dnf info <pkg> に相当し、dnf list --showduplicates <pkg> を追加すると提供されているすべてのバージョンを確認できます。
apt-mark hold は dnf versionlock add に相当し、python3-dnf-plugin-versionlock に記述します。
/etc/apt/preferences.d/ の Pinning は、リポジトリセクションの priority= に相当します。数値の大小関係は逆です。
dpkg -S /path/to/file は rpm -qf /path/to/file に相当します。

自動更新は、構文ではなく考え方として置き換えます。ここには unattended-upgrades がないためです。タイマー、設定ファイル、再起動するかどうかについては、Rocky と Alma での dnf-automatic で説明します。

リポジトリの一覧は短く保つ

CRB を有効にして epel-release をインストールし、実施した内容と理由を構成管理、またはサーバー上の通常のファイルに記録します。サーバーが導入から 3 年経過し、別の担当者が管理する状況になると、この記録は想像以上に役立ちます。

追加する前に検索します。dnf search を実行し、続いて dnf info を実行してから、新しいリポジトリの追加を検討します。EPEL を有効にする理由のうち、実際には AppStream にすでに含まれているものがかなりあります。システム監視がその代表例です。Performance Co-Pilot はベースリポジトリに含まれているため、サードパーティのリポジトリは必要ありません。追加するリポジトリが増えるたびに、火曜日にパッケージを提供できる相手が増えます。また、次回のメジャーアップグレードも難しくなります。

まだ 2 つのディストリビューションのどちらを選ぶか決めていない場合でも、この構成はどちらも同じで、epel-release も同じように動作します。実際の違いは別の部分にあります。Rocky Linux と AlmaLinux の比較では、再構築方針の違いを説明しています。AlmaLinux は現在、1 行単位の再構築ではなく、ABI（application binary interface）互換性を目標にしています。

FAQ

Rocky Linux 9 または AlmaLinux 9 で EPEL を有効にするにはどうすればよいですか？

まず sudo dnf install -y dnf-plugins-core、次に sudo dnf config-manager --set-enabled crb、その後 sudo dnf install -y epel-release を実行します。dnf repolist --enabled で確認すると、baseos、appstream、extras、crb、epel が表示されるはずです。EPEL パッケージをインストールする前に CRB を有効にしてください。多くのパッケージが CRB でのみ提供されるライブラリに依存しているためです。バージョン 8 では、リポジトリー ID は crb ではなく powertools です。

本番サーバーで EPEL を有効にしても安全ですか？

EPEL は広く利用されており、EPEL パッケージがベースディストリビューションのパッケージを置き換えないという方針に基づいて構築されています。そのため、有効にしても BaseOS や AppStream が提供する内容は変わりません。注意点はサポートです。EPEL はボランティアによる Fedora プロジェクトであり、サービスレベル契約はありません。また、メンテナーがパッケージを維持する期間は、RHEL のマイナーリリース 1 つ分、または 13 か月程度にとどまる場合があります。dnf repository-packages epel list installed でインベントリを保持し、顧客向けサービスが依存する EPEL パッケージには dnf versionlock を使用してください。

dnf で no such command: config-manager と表示されるのはなぜですか？

config-manager は組み込みコマンドではなく dnf プラグインだからです。minimal イメージやコンテナイメージには、dnf-plugins-core が含まれていません。メッセージ自体に対処方法が示されています。シェルが括弧を解釈しないように引用符で囲んだ sudo dnf install -y 'dnf-command(config-manager)' を実行してください。まだ何もインストールできない場合は grep -rl crb /etc/yum.repos.d/ を実行し、表示されたファイルを開いて、[crb] セクションの enabled=1 を手動で設定します。

CRB と PowerTools の違いは何ですか？

同じリポジトリーを異なる名前で呼んでいます。バージョン 8 では PowerTools と呼び、ID は powertools です。バージョン 9 以降では CRB と呼び、ID は crb です。Red Hat の製品では、このコンテンツを CodeReady Linux Builder と呼びます。開発用ヘッダー、静的ライブラリ、ビルド時ツールを提供し、Rocky および AlmaLinux 9 ではデフォルトで無効になっています。AlmaLinux 10 では 10.0 からデフォルトで有効になっているため、そこで有効化コマンドを実行する前に dnf repolist --enabled を確認してください。

既存の構成を壊さずに EPEL を削除するにはどうすればよいですか？

まず dnf repository-packages epel list installed でインベントリを確認してください。epel-release パッケージだけを削除しても、EPEL からインストールしたパッケージは削除されないためです。それらのパッケージはディスク上に残り、更新元を失います。また、エラーが表示されないままセキュリティ修正も受け取れなくなります。パッケージごとに判断し、不要になったものを削除または置き換えてから sudo dnf remove epel-release を実行してください。EPEL のパッケージが別のパッケージを置き換えておらず、単純に削除する必要がある場合は、sudo dnf repository-packages epel remove で一度のトランザクションでセット全体を削除できます。実行を確定する前に、提案された一覧を慎重に確認してください。

#rocky-linux #almalinux #dnf#epel#repositories