Pakket niet gevonden in Rocky Linux of AlmaLinux

Waarom dnf het gewenste pakket niet kan vinden

EPEL en CRB zijn de twee repositories die een verse Rocky Linux- of AlmaLinux-server niet standaard aanbiedt. Daarom reageert dnf install htop op een nieuwe machine met No match for argument: htop en vervolgens Error: Unable to find a match: htop. Er is niets defect en er is geen mirror offline. De basisdistributie levert bewust een beperkte set pakketten, CRB is aanwezig maar uitgeschakeld, en EPEL is een afzonderlijke community-repository die u zelf moet toevoegen.

Op Ubuntu bevindt hetzelfde pakket zich in universe, en universe is op vrijwel elke cloud-image ingeschakeld, waardoor deze vraag nooit opkomt. De Red Hat-familie verdeelt haar pakketten anders en kiest standaard voor minder. De oplossing bestaat uit drie commando's. De rest van deze handleiding behandelt het deel dat niemand u in de eerste week vertelt: wat deze repositories beloven, wat ze niet beloven, en hoe u voorkomt dat een externe repository stilletjes uw basissysteem overneemt.

Hoe deze commando's zijn gecontroleerd. Onze testcontainers voor commando's draaien uitsluitend op Ubuntu, dus de dnf-commando's hieronder zijn niet op onze eigen testmachines uitgevoerd. Ze volgen de documentatie van Rocky Linux en AlmaLinux. Elke stap benoemt de output die u hoort te zien; controleer daarom elke stap op uw eigen server in plaats van het hele blok in één keer te plakken.

Wat zijn BaseOS, AppStream en CRB?

BaseOS is het besturingssysteem zelf: de kernel, glibc, systemd en de kern van de userland. Versies in dit onderdeel veranderen zelden tijdens de levenscyclus van de major release. De meeste fixes, inclusief beveiligingsupdates, worden teruggepoort naar de versie die u al heeft, hoewel een minor release soms een kerncomponent bijwerkt naar een nieuwere upstream-versie (AlmaLinux 9.2 werkte bijvoorbeeld de SELinux user-space pakketten bij naar versie 3.5). Een versienummer in BaseOS dat jaren oud lijkt, is geen ongepatcht pakket. Het is een gepatchte oude versie, wat precies het doel is van een enterprise-distributie.

AppStream bevat de software die u bovenop het systeem draait: webservers, databases, language runtimes, editors en monitoring-agents. In versie 8 werd een groot deel van AppStream geleverd als modules met alternatieve streams, waardoor dnf module list belangrijk was en u bijvoorbeeld één specifieke PHP-stream koos. Versie 9 levert de standaardversie van elke applicatie als een gewoon pakket, dus op Rocky 9 en Alma 9 geeft een standaard dnf install u die versie zonder dat u eerst een module hoeft in te schakelen. Alternatieve versies worden nog steeds geleverd als module-streams: RHEL 9 documenteert PHP 8.0 als het gewone php-pakket en PHP 8.1 en 8.2 als de php:8.1- en php:8.2-streams, en AlmaLinux 9.8 voegde nieuwe streams toe zoals MariaDB 11.8, PostgreSQL 18 en Ruby 4.0. Als u iets anders nodig heeft dan de standaardversie, is dnf module list op versie 9 nog steeds van belang.

Extras is standaard ingeschakeld en is erg klein. Het bevat voornamelijk release-pakketten voor andere repositories, waar ook epel-release vandaan komt. Dat detail is de reden waarom u nooit een willekeurige URL hoeft te vertrouwen om EPEL op Rocky of Alma te installeren.

CRB is de CodeReady Builder-repository, die in versie 8 PowerTools werd genoemd. Deze bevat de build-kant van de distributie: development headers, statische bibliotheken en de test- en documentatietools die pakketten nodig hebben tijdens het build-proces. Deze repository staat al op de mirror en is standaard uitgeschakeld. Bij het eigen product van Red Hat heet dezelfde inhoud CodeReady Linux Builder; dit wordt meegeleverd met het abonnement, maar Red Hat stelt dat dit niet onder de ondersteuning valt. Rocky en Alma nemen zowel de inhoud als de standaard uitgeschakelde status over.

Voor lezers die afkomstig zijn van Debian of Ubuntu: main mengt runtime-pakketten en -dev-headers in één archief, dus daar is geen CRB om in te schakelen. De dichtstbijzijnde tegenhanger van EPEL is universe, dat door de community wordt onderhouden en geen ondersteuningsgarantie van de leverancier biedt.

Wat EPEL is en wie erachter staat

EPEL staat voor Extra Packages for Enterprise Linux. Het is een Fedora-project: pakketten die in Fedora bestaan, worden opnieuw gebouwd voor de huidige enterprise-release. Ze worden onderhouden door de EPEL Special Interest Group, die grotendeels uit vrijwilligers van de Fedora-community bestaat. Red Hat faciliteert de build- en mirror-infrastructuur en enkele Red Hat-engineers onderhouden pakketten in de repository. Daar houdt de relatie op. EPEL is geen product van Red Hat. Er is geen ondersteuningscontract en geen SLA (service level agreement) verbonden aan een EPEL-pakket, noch op RHEL, noch op een rebuild.

Eén beleidsregel maakt het veilig om EPEL in te schakelen: een EPEL-pakket mag nooit een pakket uit de basisdistributie vervangen. Als AppStream nginx levert, zal EPEL dat niet doen. Die regel wordt afgedwongen door de personen die EPEL-pakketten beoordelen; het is dus een garantie die uitsluitend voor EPEL geldt. Het beschermt u niet tegen andere zaken die u later toevoegt.

De levensduurverwachting verschilt ook van de basisdistributie, en dit is wat in het derde jaar voor problemen kan zorgen. Een BaseOS-pakket behoudt doorgaans zijn versie gedurende de volledige tienjarige levensduur van de major release, waarbij fixes worden teruggepoort en slechts incidenteel een bewuste rebase plaatsvindt. Een EPEL-beheerder committeert zich aan een veel korter venster: het voorstel voor de levensduur van EPEL-pakketten stelt dat dit ten minste één RHEL minor release of 13 maanden is, afhankelijk van wat korter is. In de praktijk worden de meeste pakketten veel langer onderhouden. Sommige worden uitgefaseerd wanneer de beheerder stopt, en sommige springen naar een nieuwe major-versie halverwege de levensduur van uw distributie, omdat EPEL Fedora volgt. Een routine-dnf upgrade kan u dus een nieuwe major-versie van een EPEL-tool bezorgen op een machine waarvan u dacht dat deze stabiel was, en een pakket waarvan u afhankelijk bent, kan stoppen met het ontvangen van updates zonder dat u daarover een aankondiging ontvangt. Een nieuwe versie wordt bovendien niet direct actief in een service die al draait, dus needs-restarting vertelt u welke processen nog op het oude binaire bestand draaien zodra de transactie is voltooid.

Nog een gevolg dat het vermelden waard is voordat u het inschakelt: EPEL wordt niet gebouwd tegen de oudere minor release waarop u een server mogelijk vasthoudt. Het EPEL-beleid van Fedora bouwt de leidende EPEL 10 minor-versie tegen CentOS Stream 10 en de volgende EPEL 10 minor-versies tegen specifieke RHEL 10 minor-releases; EPEL 8 en 9 hebben hun eigen doeldefinities. Als u een server op een oudere minor-versie houdt door gebruik te maken van een bevroren mirror of een vendor point release-repository, kan een EPEL-pakket een nieuwere basisbibliotheek vereisen dan degene die u heeft. dnf rapporteert dit als een ontbrekende afhankelijkheid, en het lijkt op een mirror-probleem terwijl het in werkelijkheid een versie-verschil (version skew) is.

CRB inschakelen en EPEL installeren op Rocky of 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 hoort nu baseos, appstream, extras, crb en epel weer te geven. Mogelijk ziet u ook een klein epel-cisco-openh264-item, dat epel-release toevoegt. Als crb ontbreekt in die lijst, is de inschakelstap niet gelukt; de volgende sectie legt uit waarom.

Op Rocky 8 en Alma 8 heet de repository nog steeds PowerTools, dus het middelste commando wordt sudo dnf config-manager --set-enabled powertools. Repository-id's zijn hoofdlettergevoelig en oudere CentOS 8-documentatie spelt het als PowerTools met hoofdletters, wat niet zal matchen. Op AlmaLinux 10 is de CRB-repository standaard ingeschakeld vanaf versie 10.0 (gewijzigd in september 2025), dus daar hoeft u alleen de epel-release-stap uit te voeren.

epel-release is afkomstig van extras, dat al is ingeschakeld, dus er is geen URL om te vertrouwen en geen sleutel om handmatig te importeren. Het pakket schrijft /etc/yum.repos.d/epel.repo en installeert de EPEL-ondertekeningssleutel onder /etc/pki/rpm-gpg/. Bevestig gpgcheck=1 in dat bestand en negeer elke handleiding die u adviseert een handtekeningfout te omzeilen met --nogpgcheck. Een mislukte handtekeningcontrole betekent dat het pakket niet is wat het beweert te zijn, of dat uw systeemklok onjuist staat.

Op Rocky installeert epel-release ook een kleine helper op /usr/bin/crb, waardoor sudo crb enable en crb status hetzelfde werk doen zonder de plugin. Controleer of u deze heeft met command -v crb voordat u erop vertrouwt, aangezien deze niet aanwezig is op elke branch van elke rebuild.

Om te bewijzen dat EPEL bereikbaar is in plaats van alleen vermeld, vraagt u om een pakket dat alleen in die repository voorkomt:

dnf repoquery --repo=epel htop

Dit toont de pakketnaam, versie en architectuur. Stilte betekent dat de repository is ingeschakeld maar niets teruggeeft; dit is meestal een mirror- of metadataprobleem in plaats van een configuratiefout, dus probeer daarna sudo dnf clean all && sudo dnf makecache.

Waarom dnf de melding 'no such command: config-manager' geeft

Dit is het eerste struikelblok voor veel gebruikers, en het komt specifiek voor bij de images die de meeste VPS-providers aanbieden.

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 is een plugin, geen ingebouwd dnf-subcommando. Het wordt meegeleverd in dnf-plugins-core, dat bij een volledige serverinstallatie automatisch wordt geïnstalleerd, maar bij minimale images, cloud-images en container-images wordt weggelaten. De suggestie van dnf zelf werkt omdat het pakket die virtuele capability declareert:

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

Plaats het tussen aanhalingstekens. De haakjes zijn shell-syntaxis; een versie zonder aanhalingstekens resulteert in een syntaxfout in plaats van een dnf-fout.

Als u de plugin niet kunt installeren omdat de benodigde repository is uitgeschakeld, bewerk dan het bestand handmatig. Zoek welk bestand de sectie bevat, open het en stel enabled=1 in onder [crb]:

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

Dat is precies wat config-manager doet, dus er gaat niets verloren door dit handmatig uit te voeren. dnf repolist --enabled bevestigt het resultaat.

Sommige EPEL-pakketten installeren niet voordat CRB is ingeschakeld

De tweede veelvoorkomende valkuil levert een foutmelding op die CRB niet noemt. Een EPEL-pakket dat linkt naar een bibliotheek die alleen in CRB wordt meegeleverd, faalt tijdens de afhankelijkheidsresolutie. De melding noemt de bibliotheek en het pakket dat deze vereist:

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

De oorzaak is dat CRB is uitgeschakeld, waardoor dnf de enige repository die deze bibliotheek aanbiedt niet kan zien. Controleer de volgende twee zaken in deze volgorde:

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

Als het tweede commando een pakket noemt terwijl de standaard installatie faalt, staat CRB uit. Dit type fout komt zo vaak voor dat AlmaLinux CRB in versie 10 standaard heeft ingeschakeld om dit te voorkomen. --enablerepo=crb werkt ook als een eenmalige vlag bij een enkele installatie, maar laat CRB permanent ingeschakeld als u EPEL gebruikt. Een volgende EPEL-update kan namelijk zonder waarschuwing een nieuwe CRB-afhankelijkheid toevoegen.

Uit welke repository is dit pakket afkomstig?

Na een paar weken met vier ingeschakelde repositories is de relevante vraag niet langer wat er is geïnstalleerd, maar waar het vandaan komt.

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 op een geïnstalleerd pakket toont een From repo-regel. dnf list installed toont dezelfde informatie in de derde kolom met een @ ervoor; zo betekent @epel dat het pakket is geïnstalleerd vanuit EPEL, en betekent @System dat dnf niet weet waar het vandaan komt, wat meestal inhoudt dat iemand rpm -i heeft uitgevoerd op een gedownload bestand. De repoquery-regel geeft een telling per repository; dit is de snelste manier om te ontdekken dat een server die u heeft overgenomen veertig pakketten bevat uit een repository waar u nog nooit van heeft gehoord. Het laatste commando geeft een exacte lijst van wat één repository u heeft geleverd, en die inventarisatie heeft u nodig voordat u besluit deze te verwijderen.

De gewoonte in apt is apt-cache policy <package>, en de dnf en apt commando equivalenten zijn het waard om de eerste maand in een tweede tabblad open te houden, omdat de concepten goed overeenkomen, zelfs als de flags dat niet doen.

Hoe voorkom ik dat een externe repository een basispakket vervangt?

EPEL belooft dit niet te doen. Geen enkele andere repository biedt deze garantie. Een vendor-repository voor een database, een agent of een runtime-omgeving kan een eigen build van een bibliotheek leveren die ook in BaseOS aanwezig is. dnf zal deze installeren, omdat de standaardregel van dnf eenvoudig is: de hoogste versie wint, ongeacht de bron.

Twee instellingen doen het meeste werk en beide bevinden zich in het repository-bestand onder /etc/yum.repos.d/.

priority= bepaalt welke repository wint wanneer meerdere repository's hetzelfde pakket aanbieden. Lagere getallen winnen en de standaardwaarde is 99. Geef uw basis-repository's daarom een laag getal en externe repository's een hoog getal. dnf kiest dan het basispakket, zelfs als de externe versie nieuwer is. Moderne dnf-versies regelen dit zelf, waardoor het afzonderlijke yum-plugin-priorities-pakket uit het CentOS 7-tijdperk niet langer nodig is.

includepkgs= is de krachtigste filteroptie. excludepkgs= blokkeert specifieke pakketten uit een repository, waarvoor u moet voorspellen wat deze zou kunnen leveren. includepkgs= werkt omgekeerd: deze repository mag uitsluitend de opgegeven pakketten leveren en niets anders. Een vendor-repository die alleen zijn eigen agent mag leveren, vereist slechts één regel.

[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

Op versie 8 is er nog één instelling die u moet kennen. Een pakket uit een externe repository kan verborgen worden wanneer een AppStream-module dezelfde naam gebruikt. module_hotfixes=1 in de sectie van die repository vertelt dnf om dit filteren te stoppen. Als een pakket dat de repository van de leverancier zeker bevat, als ontbrekend wordt gerapporteerd of niet wil installeren op een systeem met versie 8, is dit meestal de oorzaak: modulaire filtering maakt het onzichtbaar voor de meeste dnf-commando's in plaats van een conflict te melden. Versie 9 heeft minder modules, maar gebruikt nog steeds module-streams, waardoor dezelfde filtering van toepassing kan zijn wanneer een vendor-pakket een naam deelt met een module.

Om één pakket vast te pinnen op één versie, installeert u python3-dnf-plugin-versionlock en gebruikt u sudo dnf versionlock add <package>. Dit is het equivalent van apt-mark hold. Let op één verschil dat vaak voor verwarring zorgt bij gebruikers die overstappen van Debian: in apt wint een hogere Pin-Priority, in dnf wint een lagere priority.

Waarom het mengen van RHEL-gerelateerde repositories een server on-upgradebaar maakt

Rocky, Alma, CentOS Stream, Oracle Linux en RHEL liggen dicht genoeg bij elkaar om pakketten op elkaars systemen te installeren, maar ze verschillen voldoende om het resultaat onondersteunbaar te maken. Waarom ze zo dicht bij elkaar liggen, en waarom Stream tegenwoordig voor RHEL uitloopt in plaats van ernaast te staan, is het verhaal van hoe Red Hat Linux splitste in Fedora en RHEL en wat er van CentOS terechtkwam.

Het mechanisme draait om versienummers. CentOS Stream 9 loopt voor op RHEL 9, en Red Hat beschrijft de code van Stream als de basis voor de volgende minor release van RHEL. Als u een Rocky 9-systeem naar een Stream-repository wijst, zelfs eenmalig of voor slechts één pakket, blijft u zitten met pakketten waarvan de versies hoger zijn dan wat Rocky momenteel aanbiedt. Een latere minor release van Rocky haalt dit wellicht in, maar er is geen garantie dat deze het pakket op of boven uw versie aanbiedt. Totdat dit gebeurt, zal dnf upgrade het pakket niet aanraken. De machine draait nu een combinatie die door niemand is getest, en dit kan jarenlang onopgemerkt blijven terwijl u ervan uitgaat dat het systeem gepatcht is.

Het symptoom is dat dnf upgrade meldt dat er niets te doen is, terwijl sudo dnf distro-sync voorstelt om een lange lijst met pakketten te downgraden. distro-sync is het reparatiegereedschap: het dwingt elk geïnstalleerd pakket om overeen te komen met wat de ingeschakelde repositories daadwerkelijk aanbieden, inclusief downgrades. Schakel eerst de externe repository uit, voer het commando uit en lees de voorgestelde lijst door voordat u deze accepteert. De reparatie faalt wanneer het oudere RPM-bestand niet langer op de mirror staat; op dat punt is het sneller en veiliger om de server vanaf een schone image opnieuw op te bouwen dan om de dependency solver te bevechten.

Restanten uit het ELevate-tijdperk zijn de andere veelvoorkomende vorm van dit probleem. ELevate is de migratietool van AlmaLinux, gebaseerd op Leapp, die wordt gebruikt om een CentOS 7-systeem te upgraden of om te converteren tussen rebuilds. Een overhaaste migratie laat EL7-repositorybestanden achter in /etc/yum.repos.d/ en EL7-pakketten die nog steeds geïnstalleerd zijn. Zoek deze op met rpm -qa | grep el7. Elk van deze pakketten kan door geen enkele ingeschakelde repository worden bijgewerkt. Een latere Leapp-run rapporteert deze als pakketten die niet kunnen worden gemapt, wat een blokkade vormt voor de upgrade die u handmatig moet oplossen. Verwijder deze pakketten terwijl de server stabiel is, niet op de dag dat u de volgende grote upgrade moet uitvoeren.

Een vendor-repository die een AppStream-pakket overschaduwt, is de milde variant van hetzelfde probleem, en de includepkgs-regel hierboven is de oplossing. Container-tooling is het meest voorkomende geval, omdat containerd.io uit de eigen repository van Docker conflicteert met runc uit AppStream; één van beide moet dus verdwijnen. Beslis één keer, noteer de uitsluiting en volg een bewezen goede volgorde: de Docker-installatie op Rocky Linux-handleiding beschrijft welke distributiepakketten u als eerste moet verwijderen.

De vertaling van apt naar dnf voor repositories

• /etc/apt/sources.list.d/*.sources wordt /etc/yum.repos.d/*.repo, waarbij één bestand meerdere [sections] kan bevatten, elk met een eigen id.
• add-apt-repository universe wordt dnf install epel-release, met het verschil dat universe zich nog steeds in het eigen archief van Ubuntu bevindt en EPEL een afzonderlijk project is.
• apt update heeft geen equivalent dat u moet onthouden. dnf ververst metadata volgens een eigen schema en dnf makecache dwingt dit nu af.
• apt-cache policy <pkg> wordt dnf info <pkg>, plus dnf list --showduplicates <pkg> om elke beschikbare versie te zien.
• apt-mark hold wordt dnf versionlock add, vanuit python3-dnf-plugin-versionlock.
• Pinning in /etc/apt/preferences.d/ wordt priority= in de repository-sectie, waarbij de getallen in omgekeerde volgorde werken.
• dpkg -S /path/to/file wordt rpm -qf /path/to/file.

Automatische updates worden eerder als concept dan als syntax overgedragen, aangezien er hier geen unattended-upgrades is. De timer, het configuratiebestand en de vraag of een herstart nodig is, worden behandeld in dnf-automatic op Rocky en Alma.

Houd de repositorylijst kort

Schakel CRB in, installeer epel-release en noteer vervolgens wat u heeft gedaan en waarom. Doe dit in uw configuratiebeheersysteem of in een tekstbestand op de server zelf. Deze aantekening is waardevoller dan het lijkt wanneer de server drie jaar oud is en iemand anders het beheer uitvoert.

Zoek voordat u iets toevoegt. Voer dnf search uit, gevolgd door dnf info, en overweeg pas daarna een nieuwe repository. Een verrassend groot deel van de software waarvoor mensen EPEL inschakelen, is al aanwezig in AppStream. Systeemmonitoring is hiervan het duidelijkste voorbeeld, aangezien Performance Co-Pilot in de basisrepositories zit en geen externe partijen vereist. Elke extra repository is een extra partij die u op een willekeurige dinsdag een pakket kan sturen, en elke toevoeging maakt de volgende grote upgrade complexer.

Als u nog steeds kiest tussen de twee distributies: deze opzet is op beide identiek en epel-release gedraagt zich op dezelfde manier. De werkelijke verschillen liggen elders: de vergelijking tussen Rocky Linux en AlmaLinux behandelt de filosofie achter de rebuild, aangezien AlmaLinux zich nu richt op ABI-compatibiliteit (application binary interface) in plaats van een exacte kopie op regelniveau.

FAQ

Hoe schakel ik EPEL in op Rocky Linux 9 of AlmaLinux 9?

Voer sudo dnf install -y dnf-plugins-core uit, gevolgd door sudo dnf config-manager --set-enabled crb en daarna sudo dnf install -y epel-release. Bevestig met dnf repolist --enabled; dit hoort baseos, appstream, extras, crb en epel weer te geven. Schakel CRB in voordat u EPEL-pakketten installeert, omdat veel van deze pakketten afhankelijk zijn van bibliotheken die alleen via CRB beschikbaar zijn. Op versie 8 is de repository-id powertools in plaats van crb.

Is het veilig om EPEL in te schakelen op een productieserver?

Het wordt op grote schaal gebruikt en is gebouwd op het beleid dat EPEL-pakketten nooit pakketten uit de basisdistributie vervangen. Het inschakelen ervan verandert dus niets aan wat BaseOS of AppStream u biedt. Het voorbehoud is de ondersteuning: EPEL is een vrijwilligersproject van Fedora zonder service level agreement. Het voorstel voor de levensduur van EPEL-pakketten vraagt van een beheerder slechts een toewijding voor de duur van één RHEL minor release of 13 maanden. Houd een inventaris bij met dnf repository-packages epel list installed en gebruik dnf versionlock voor elk EPEL-pakket waarvan een klantgerichte service afhankelijk is.

Waarom geeft dnf de melding no such command: config-manager?

Omdat config-manager een dnf-plugin is en geen ingebouwd commando, en minimale images of container-images worden geleverd zonder dnf-plugins-core. De melding zelf geeft de oplossing: sudo dnf install -y 'dnf-command(config-manager)', tussen aanhalingstekens zodat de shell de haakjes niet interpreteert. Als u nog niets kunt installeren, voer dan grep -rl crb /etc/yum.repos.d/ uit, open het genoemde bestand en stel handmatig enabled=1 in onder de sectie [crb].

Wat is het verschil tussen CRB en PowerTools?

Dit is dezelfde repository onder twee verschillende namen. Versie 8 noemt het PowerTools met de id powertools, versie 9 en later noemen het CRB met de id crb, en het eigen product van Red Hat noemt de inhoud CodeReady Linux Builder. Het bevat development headers, statische bibliotheken en build-tools, en is standaard uitgeschakeld op Rocky en AlmaLinux 9. AlmaLinux 10 schakelt dit vanaf 10.0 standaard in, dus controleer dnf repolist --enabled voordat u daar het inschakelcommando uitvoert.

Hoe verwijder ik EPEL weer zonder zaken te verbreken?

Inventariseer eerst met dnf repository-packages epel list installed, omdat het verwijderen van alleen het pakket epel-release niets verwijdert dat vanuit EPEL is geïnstalleerd. Die pakketten blijven op de schijf staan, verliezen hun bron voor updates en ontvangen geen beveiligingspatches meer, zonder dat u hiervan een foutmelding krijgt. Beslis per pakket, verwijder of vervang wat u niet langer nodig heeft, en voer pas daarna sudo dnf remove epel-release uit. Als iets uit EPEL niets heeft vervangen en absoluut weg moet, wist sudo dnf repository-packages epel remove de set in één transactie. Lees de voorgestelde lijst daarom zorgvuldig door voordat u deze bevestigt.