Activer EPEL et CRB sur Rocky Linux et AlmaLinux

Pourquoi dnf ne trouve pas le paquet que vous cherchez

EPEL et CRB sont les deux dépôts qu’un serveur Rocky Linux ou AlmaLinux fraîchement installé n’active pas par défaut. C’est pourquoi dnf install htop sur une nouvelle machine renvoie No match for argument: htop, puis Error: Unable to find a match: htop. Rien n’est cassé et aucun miroir n’est hors service. La distribution de base fournit volontairement un nombre limité de paquets. CRB est présent, mais désactivé. EPEL est un dépôt communautaire distinct que vous devez ajouter.

Sur Ubuntu, le même paquet se trouve dans universe, et universe est activé sur presque toutes les images cloud. La question ne se pose donc jamais. La famille Red Hat répartit ses paquets différemment et en fournit moins par défaut. La correction tient en trois commandes. La suite de ce guide aborde ce que personne ne vous explique pendant la première semaine : ce que ces dépôts garantissent, ce qu’ils ne garantissent pas et comment empêcher un dépôt tiers de prendre discrètement le contrôle de votre système de base.

Comment ces commandes ont été vérifiées. Nos conteneurs de test des commandes exécutent uniquement Ubuntu. Les commandes dnf ci-dessous n’ont donc pas été exécutées sur nos propres machines de test. Elles suivent la documentation de Rocky Linux et d’AlmaLinux. Chaque étape indique la sortie attendue. Vérifiez-la sur votre propre serveur au lieu de coller tout le bloc en une seule fois.

Que sont BaseOS, AppStream et CRB ?

BaseOS constitue le système d’exploitation lui-même : le noyau, glibc, systemd et l’espace utilisateur de base. Les versions changent rarement pendant le cycle de vie de la version majeure. La plupart des correctifs, y compris les correctifs de sécurité, sont rétroportés dans la version déjà installée. Une version mineure peut toutefois remplacer un composant principal par une version amont plus récente. AlmaLinux 9.2, par exemple, a mis à jour les paquets de l’espace utilisateur SELinux vers la version 3.5. Un numéro de version qui semble ancien dans BaseOS ne correspond pas à un paquet non corrigé. Il s’agit d’une ancienne version corrigée. C’est précisément le principe d’une distribution d’entreprise.

AppStream contient les logiciels exécutés par-dessus le système : serveurs web, bases de données, environnements d’exécution, éditeurs et agents de supervision. En version 8, une grande partie d’AppStream était fournie sous forme de modules avec différents streams. dnf module list était donc important et vous deviez choisir, par exemple, un stream PHP. La version 9 fournit la version par défaut de chaque application sous forme de paquet standard. Sur Rocky 9 et Alma 9, un simple dnf install installe donc cette version, sans devoir activer un module au préalable. Les autres versions sont toujours fournies sous forme de module streams. RHEL 9 documente PHP 8.0 comme paquet php standard, et PHP 8.1 et 8.2 comme streams php:8.1 et php:8.2. AlmaLinux 9.8 a également ajouté de nouveaux streams, notamment MariaDB 11.8, PostgreSQL 18 et Ruby 4.0. Si vous avez besoin d’une version différente de la version par défaut, dnf module list reste donc important en version 9.

Extras est activé par défaut et son contenu est très limité. Il contient principalement les paquets de release d’autres dépôts. C’est de là que provient epel-release lui-même. C’est pourquoi vous n’avez jamais besoin de faire confiance à une URL quelconque pour installer EPEL sur Rocky ou Alma.

CRB est le dépôt CodeReady Builder, appelé PowerTools en version 8. Il contient les éléments nécessaires à la compilation : en-têtes de développement, bibliothèques statiques, ainsi que les outils de test et de documentation requis par les paquets lors de leur compilation. Il est déjà présent sur le miroir, mais désactivé par défaut. Dans le produit Red Hat, le même contenu s’appelle CodeReady Linux Builder. Il est fourni avec l’abonnement, et Red Hat précise qu’il n’est pas couvert par le support. Rocky et Alma reprennent à la fois ce contenu et cette désactivation par défaut.

Pour les lecteurs venant de Debian ou d’Ubuntu : main regroupe les paquets d’exécution et les en-têtes -dev dans une seule archive. Il n’y a donc pas de CRB à activer. L’équivalent le plus proche d’EPEL est universe. Ce dépôt est maintenu par la communauté et ne bénéficie d’aucun engagement de support de l’éditeur.

Ce qu’est EPEL et qui le maintient

EPEL signifie Extra Packages for Enterprise Linux. Il s’agit d’un projet Fedora : des packages présents dans Fedora, reconstruits pour la version Enterprise actuelle et maintenus par l’ EPEL Special Interest Group, composé principalement de bénévoles de la communauté Fedora. Red Hat héberge l’infrastructure de build et de miroir, et certains ingénieurs Red Hat maintiennent des packages dans ce dépôt. La relation s’arrête là. EPEL n’est pas un produit Red Hat. Aucun contrat de support ni aucun SLA (service level agreement) ne couvre un package EPEL, sur RHEL comme sur une reconstruction.

Une règle rend EPEL utilisable sans remplacer les packages de la distribution de base : un package EPEL ne doit jamais remplacer un package fourni par la distribution de base. Si AppStream fournit nginx, EPEL ne le fournira pas. Cette règle est appliquée par les personnes qui vérifient les packages EPEL. Elle ne constitue donc un engagement que pour EPEL. Elle ne vous protège pas contre les autres dépôts que vous ajouterez ensuite.

La durée de maintenance diffère également de celle de la distribution de base. C’est souvent en troisième année que le problème apparaît. Un package BaseOS conserve généralement la même version pendant les dix années de vie de la version majeure, avec des correctifs rétroportés et seulement quelques changements de base planifiés. Un mainteneur EPEL s’engage sur une période beaucoup plus courte : la proposition d’EPEL sur la durée de vie des packages selon la version indique au moins une version mineure de RHEL ou 13 mois, selon la période la plus courte. En pratique, la plupart des packages sont maintenus bien plus longtemps. Certains sont retirés lorsque leur mainteneur passe à autre chose. D’autres passent à une nouvelle version majeure au milieu de la durée de vie de votre distribution, car EPEL suit Fedora. Ainsi, une mise à jour dnf upgrade courante peut installer une nouvelle version majeure d’un outil EPEL sur une machine que vous pensiez stable. Un package dont vous dépendez peut également cesser de recevoir des mises à jour sans annonce qui vous parvienne. Une nouvelle version ne s’applique pas non plus à un service déjà en cours d’exécution. needs-restarting vous indique donc quels processus utilisent encore l’ancien binaire une fois la transaction terminée.

Il faut également connaître une autre conséquence avant d’activer EPEL : les packages EPEL ne sont pas construits pour l’ancienne version mineure sur laquelle vous maintenez peut-être un serveur. La politique EPEL de Fedora construit la version mineure EPEL 10 la plus récente avec CentOS Stream 10, et les versions mineures EPEL 10 précédentes avec des versions mineures précises de RHEL 10. EPEL 8 et 9 ont leurs propres définitions de cible. Si vous conservez un serveur sur une ancienne version mineure, avec un miroir figé ou un dépôt de version intermédiaire fourni par un éditeur, un package EPEL peut nécessiter une bibliothèque de base plus récente que celle dont vous disposez. dnf signale alors une dépendance manquante. Le problème ressemble à un problème de miroir, alors qu’il s’agit en réalité d’un décalage de versions.

Activer CRB et installer EPEL sur Rocky ou Alma

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 doit maintenant afficher baseos, appstream, extras, crb et epel. Vous pouvez également voir une petite entrée epel-cisco-openh264, ajoutée par epel-release. Si crb n’apparaît pas dans cette liste, l’activation n’a pas fonctionné. La section suivante en explique la raison.

Sur Rocky 8 et Alma 8, le dépôt s’appelle encore PowerTools. La commande intermédiaire devient donc sudo dnf config-manager --set-enabled powertools. Les identifiants de dépôt sont sensibles à la casse. Les anciennes documentations CentOS 8 l’écrivent PowerTools avec des majuscules, ce qui ne correspond pas. Sur AlmaLinux 10, le dépôt CRB est activé par défaut depuis 10.0, à la suite d’un changement effectué en septembre 2025. Vous devez donc seulement exécuter l’étape epel-release.

epel-release provient de extras, qui est déjà activé. Vous n’avez donc aucune URL à approuver ni aucune clé à importer manuellement. Le paquet écrit /etc/yum.repos.d/epel.repo et installe la clé de signature EPEL dans /etc/pki/rpm-gpg/. Vérifiez gpgcheck=1 dans ce fichier et ignorez tout guide qui vous demande de contourner une erreur de signature avec --nogpgcheck. Un échec de la vérification de signature signifie que le paquet n’est pas celui qu’il prétend être, ou que votre horloge est incorrecte.

Sur Rocky, epel-release installe également un petit utilitaire dans /usr/bin/crb. Ainsi, sudo crb enable et crb status effectuent la même opération sans le plugin. Vérifiez sa présence avec command -v crb avant de l’utiliser, car il n’est pas disponible dans toutes les branches de chaque rebuild.

Pour vérifier qu’EPEL est accessible et pas seulement répertorié, demandez-lui un paquet qu’il est le seul à fournir :

dnf repoquery --repo=epel htop

La commande affiche le nom du paquet, sa version et son architecture. L’absence de sortie signifie que le dépôt est activé mais ne renvoie rien. Il s’agit généralement d’un problème de miroir ou de métadonnées, et non d’un problème de configuration. Essayez ensuite sudo dnf clean all && sudo dnf makecache.

Pourquoi dnf indique « no such command: config-manager »

C’est le premier point qui bloque souvent, et cela se produit précisément avec les images fournies par la plupart des hébergeurs 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 est un plugin, pas une sous-commande intégrée de dnf. Il est fourni dans dnf-plugins-core, qu’une installation complète du serveur installe, mais que les images minimales, les images cloud et les images de conteneur n’incluent pas. La suggestion de dnf fonctionne parce que le paquet déclare cette capacité virtuelle :

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

Mettez-la entre guillemets. Les parenthèses relèvent de la syntaxe du shell. Sans guillemets, la commande échoue avec une erreur de syntaxe, et non avec une erreur dnf.

Si vous ne pouvez pas installer le plugin parce que le dépôt dont vous avez besoin est celui qui est désactivé, modifiez directement le fichier. Trouvez le fichier qui contient la section, ouvrez-le, puis définissez enabled=1 sous [crb] :

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

C’est exactement ce que config-manager écrit. Vous ne perdez donc rien en le faisant manuellement. dnf repolist --enabled confirme le résultat.

Certains paquets EPEL ne s’installent pas tant que CRB n’est pas activé

Le deuxième piège courant produit une erreur qui ne mentionne jamais CRB. Un paquet EPEL qui dépend d’une bibliothèque fournie uniquement par CRB échoue lors de la résolution des dépendances. Le message indique le nom de la bibliothèque et du paquet qui en a besoin :

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

La cause est que CRB est désactivé. dnf ne peut donc pas voir l’unique dépôt qui fournit cette bibliothèque. Vérifiez les deux éléments dans l’ordre :

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

Si la deuxième commande indique un paquet alors que l’installation simple échoue toujours, CRB est désactivé. Cette erreur est suffisamment courante pour qu’AlmaLinux active CRB par défaut dans la version 10 afin d’éviter qu’elle se produise. --enablerepo=crb fonctionne également comme option ponctuelle lors d’une seule installation. Toutefois, laissez CRB activé en permanence si vous utilisez EPEL, car la prochaine mise à jour EPEL peut introduire une nouvelle dépendance CRB sans vous en avertir.

De quel dépôt ce paquet provient-il ?

Après quelques semaines avec quatre dépôts activés, la question utile n’est plus de savoir ce qui est installé, mais d’où cela provient.

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 sur un paquet installé affiche une ligne From repo. dnf list installed présente les mêmes informations dans sa troisième colonne, précédées de @. Ainsi, @epel signifie que le paquet a été installé depuis EPEL, tandis que @System signifie que dnf ne sait pas d’où il provient. Cela indique généralement que quelqu’un a exécuté rpm -i sur un fichier téléchargé. La ligne repoquery fournit un décompte par dépôt. C’est le moyen le plus rapide de découvrir qu’un serveur dont vous avez hérité contient quarante paquets provenant d’un dépôt dont vous n’avez jamais entendu parler. La dernière commande liste précisément ce qu’un dépôt vous a fourni. Cet inventaire est nécessaire avant de décider de le supprimer.

Avec apt, l’habitude correspondante est apt-cache policy <package>. Les équivalences de commandes entre dnf et apt méritent de rester ouvertes dans un deuxième onglet pendant le premier mois, car les concepts correspondent bien, même lorsque les options diffèrent.

Comment empêcher un dépôt tiers de remplacer un paquet de base ?

EPEL promet de ne pas le faire. Aucun autre dépôt ne le garantit. Le dépôt d’un éditeur pour une base de données, un agent ou un runtime de langage peut fournir sa propre version d’une bibliothèque également fournie par BaseOS, et dnf l’installera, car sa règle par défaut est simple : la version la plus élevée l’emporte, quelle que soit son origine.

Deux mécanismes de contrôle font l’essentiel du travail. Ils se trouvent tous les deux dans le fichier du dépôt sous /etc/yum.repos.d/.

priority= détermine quel dépôt l’emporte lorsque plusieurs dépôts portent le même nom de paquet. Les valeurs les plus basses sont prioritaires et la valeur par défaut est 99. Attribuez donc une valeur basse à vos dépôts de base et une valeur élevée aux dépôts tiers. dnf sélectionnera alors le paquet de base même si la version du dépôt tiers est plus récente. Les versions modernes de dnf gèrent cela directement. Le paquet séparé yum-plugin-priorities de l’époque de CentOS 7 ne fait donc plus partie de la solution.

includepkgs= est l’option de filtrage la plus stricte. excludepkgs= bloque dans un dépôt les paquets nommés, ce qui vous oblige à anticiper ce qu’il pourrait fournir. includepkgs= inverse le comportement : ce dépôt peut fournir ces noms, et rien d’autre. Pour un dépôt d’éditeur qui ne doit fournir que son propre agent, une seule ligne suffit.

[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

Avec la version 8, un autre paramètre est à connaître. Un paquet d’un dépôt tiers peut être masqué lorsqu’un module AppStream fournit le même nom. module_hotfixes=1, dans la section de ce dépôt, indique à dnf de cesser de le filtrer. Si un paquet que le dépôt de l’éditeur fournit bien est signalé comme absent ou refuse de s’installer sur un système en version 8, c’est généralement la cause : le filtrage modulaire le rend invisible à la plupart des commandes dnf au lieu de signaler un conflit. La version 9 contient moins de modules, mais fournit encore des flux de modules. Le même filtrage peut donc s’y appliquer lorsqu’un paquet d’éditeur porte le même nom qu’un paquet modulaire.

Pour figer un paquet sur une version donnée, installez python3-dnf-plugin-versionlock et utilisez sudo dnf versionlock add <package>. C’est l’équivalent de apt-mark hold. Notez une inversion qui surprend les personnes venant de Debian : dans apt, une valeur Pin-Priority plus élevée est prioritaire ; dans dnf, c’est une valeur priority plus basse.

Pourquoi mélanger des dépôts proches de RHEL rend un serveur impossible à mettre à niveau

Rocky, Alma, CentOS Stream, Oracle Linux et RHEL sont suffisamment proches pour que leurs paquets s’installent les uns sur les autres, mais suffisamment différents pour que le résultat ne soit plus un système que l’on puisse prendre en charge. La raison de cette proximité, et le fait que Stream se situe désormais en amont de RHEL plutôt qu’à côté, sont expliqués dans l’histoire de la séparation de Red Hat Linux en Fedora et RHEL et de l’évolution de CentOS.

Le mécanisme repose sur les numéros de version. CentOS Stream 9 évolue en amont de RHEL 9, et Red Hat décrit le code de Stream comme celui qui devient la prochaine version mineure de RHEL. Si vous pointez un serveur Rocky 9 vers un dépôt Stream, même une seule fois et pour un seul paquet, vous vous retrouvez avec des paquets dont les versions sont supérieures à celles actuellement fournies par Rocky. Une version mineure ultérieure de Rocky peut rattraper son retard, mais rien ne garantit qu’elle fournisse ce paquet avec une version égale ou supérieure à la vôtre. Tant que ce n’est pas le cas, dnf upgrade ne le modifiera pas. La machine exécute alors une combinaison que personne n’a testée. Cette situation peut rester silencieuse pendant des années pendant que vous pensez que le serveur reçoit bien ses mises à jour.

Le symptôme est que dnf upgrade n’indique rien à faire, tandis que sudo dnf distro-sync propose de rétrograder une longue liste de paquets. distro-sync est l’outil de réparation : il force tous les paquets installés à correspondre à ce que proposent réellement les dépôts activés, y compris en effectuant les rétrogradations nécessaires. Désactivez d’abord le dépôt étranger, puis exécutez l’outil et examinez la liste proposée avant de l’accepter. La réparation échoue lorsque l’ancien RPM n’est plus disponible sur le miroir. Dans ce cas, recréer le serveur à partir d’une image propre est plus rapide et plus sûr que de lutter avec le résolveur de dépendances.

Les restes d’ELevate constituent l’autre forme courante de ce problème de versions. ELevate est l’outil de migration d’AlmaLinux basé sur Leapp. Il sert à faire évoluer un serveur CentOS 7 ou à le convertir vers un autre rebuild. Une migration effectuée dans l’urgence laisse des fichiers de dépôts EL7 dans /etc/yum.repos.d/ et des paquets EL7 toujours installés. Recherchez-les avec rpm -qa | grep el7. Chacun correspond à un paquet qu’aucun dépôt activé ne pourra jamais mettre à jour. Lors d’une exécution ultérieure de Leapp, ces paquets sont signalés comme impossibles à mapper. Ils deviennent alors un blocage de mise à niveau qu’il faut supprimer manuellement. Supprimez-les lorsque le serveur fonctionne normalement, pas le jour où vous devez effectuer la prochaine mise à niveau majeure.

Un dépôt fournisseur qui masque un paquet AppStream est la version bénigne du même problème. La ligne includepkgs ci-dessus permet de le corriger. Les outils de conteneurs sont le cas le plus courant, car containerd.io provenant du propre dépôt de Docker entre en conflit avec runc provenant d’AppStream. Il faut donc supprimer l’un des deux. Prenez cette décision une fois, notez l’exclusion et suivez un ordre éprouvé : le guide installation de Docker sur Rocky Linux indique quels paquets de la distribution supprimer en premier.

Traduction d’apt vers dnf pour les dépôts

• /etc/apt/sources.list.d/*.sources devient /etc/yum.repos.d/*.repo : un fichier peut contenir plusieurs [sections], chacun avec son propre identifiant.
• add-apt-repository universe devient dnf install epel-release. La différence est que universe fait toujours partie de l’archive Ubuntu, tandis qu’EPEL est un projet distinct.
• apt update n’a pas d’équivalent à retenir. dnf actualise les métadonnées selon son propre calendrier, et dnf makecache force cette actualisation immédiatement.
• apt-cache policy <pkg> devient dnf info <pkg>, avec dnf list --showduplicates <pkg> en plus pour afficher toutes les versions disponibles.
• apt-mark hold devient dnf versionlock add, à partir de python3-dnf-plugin-versionlock.
• Le pinning dans /etc/apt/preferences.d/ devient priority= dans la section du dépôt, avec des nombres qui évoluent en sens inverse.
• dpkg -S /path/to/file devient rpm -qf /path/to/file.

Les mises à jour automatiques se transposent comme concept plutôt que comme syntaxe, car il n’existe pas de unattended-upgrades ici. Le timer, le fichier de configuration et la question d’un éventuel redémarrage sont traités dans dnf-automatic sur Rocky et Alma.

Réduisez la liste des dépôts

Activez CRB, installez epel-release, puis consignez ce que vous avez fait et pourquoi, soit dans votre gestion de configuration, soit dans un fichier texte sur le serveur. Cette note prend toute sa valeur lorsque le serveur a trois ans et qu’une autre personne en assure la maintenance.

Recherchez avant d’ajouter. Exécutez dnf search, puis dnf info, et n’envisagez l’ajout d’un nouveau dépôt qu’ensuite. Une part étonnamment importante des logiciels pour lesquels EPEL est activé se trouve déjà dans AppStream. La supervision système en est l’exemple le plus évident, puisque Performance Co-Pilot est disponible dans les dépôts de base et ne nécessite aucun dépôt tiers. Chaque dépôt supplémentaire ajoute un fournisseur susceptible de vous livrer un package un mardi, et chacun complique la prochaine mise à niveau majeure.

Si vous hésitez encore entre les deux distributions, cette organisation est identique sur les deux, et epel-release se comporte de la même manière. Les véritables différences se trouvent ailleurs : la comparaison entre Rocky Linux et AlmaLinux présente leur approche respective des rebuilds, car AlmaLinux vise désormais la compatibilité ABI (application binary interface), plutôt qu’un rebuild ligne par ligne.

FAQ

Comment activer EPEL sur Rocky Linux 9 ou AlmaLinux 9 ?

Exécutez sudo dnf install -y dnf-plugins-core, puis sudo dnf config-manager --set-enabled crb, puis sudo dnf install -y epel-release. Vérifiez avec dnf repolist --enabled, qui doit afficher baseos, appstream, extras, crb et epel. Activez CRB avant d’installer les paquets EPEL, car beaucoup d’entre eux dépendent de bibliothèques fournies uniquement par CRB. En version 8, l’identifiant du dépôt est powertools au lieu de crb.

Est-il sûr d’activer EPEL sur un serveur de production ?

EPEL est largement utilisé et repose sur une règle selon laquelle ses paquets ne remplacent jamais un paquet de la distribution de base. Son activation ne modifie donc pas le contenu fourni par BaseOS ou AppStream. La limite concerne le support : EPEL est un projet Fedora maintenu par des bénévoles, sans accord de niveau de service, et la proposition de durée de vie des paquets EPEL demande à un mainteneur de s’engager sur un paquet pour une seule version mineure de RHEL ou pour 13 mois. Tenez un inventaire avec dnf repository-packages epel list installed et utilisez dnf versionlock pour tout paquet EPEL dont dépend un service exposé aux clients.

Pourquoi dnf indique-t-il « no such command: config-manager » ?

Parce que config-manager est un plugin dnf et non une commande intégrée, et que les images minimales ou de conteneur sont livrées sans dnf-plugins-core. Le message indique directement la solution : sudo dnf install -y 'dnf-command(config-manager)', entre guillemets pour empêcher le shell d’interpréter les parenthèses. Si vous ne pouvez encore rien installer, exécutez grep -rl crb /etc/yum.repos.d/, ouvrez le fichier indiqué et définissez manuellement enabled=1 dans la section [crb].

Quelle est la différence entre CRB et PowerTools ?

Il s’agit du même dépôt sous deux noms. La version 8 l’appelle PowerTools et utilise l’identifiant powertools. La version 9 et les suivantes l’appellent CRB et utilisent l’identifiant crb. Le produit de Red Hat correspondant appelle ce contenu CodeReady Linux Builder. Ce dépôt contient des en-têtes de développement, des bibliothèques statiques et des outils de compilation. Il est désactivé par défaut sur Rocky et sur AlmaLinux 9. AlmaLinux 10 l’active par défaut depuis 10.0. Vérifiez donc dnf repolist --enabled avant d’exécuter la commande d’activation.

Comment supprimer EPEL sans rien casser ?

Commencez par établir un inventaire avec dnf repository-packages epel list installed, car la suppression du seul paquet epel-release ne supprime aucun paquet installé depuis EPEL. Ces paquets restent sur le disque, ne reçoivent plus de mises à jour et ne bénéficient plus des correctifs de sécurité, sans qu’aucune erreur ne vous en informe. Examinez-les un par un, supprimez ou remplacez ceux dont vous n’avez plus besoin, puis exécutez seulement sudo dnf remove epel-release. Si un paquet provenant d’EPEL n’a remplacé aucun paquet et doit simplement être supprimé, sudo dnf repository-packages epel remove supprime l’ensemble en une seule transaction. Lisez attentivement la liste proposée avant de confirmer.