Rocky Linux i AlmaLinux: jak dodać EPEL oraz CRB

Dlaczego dnf nie znajduje żądanego pakietu

EPEL oraz CRB to dwa repozytoria, których świeżo zainstalowany serwer Rocky Linux lub AlmaLinux nie udostępnia domyślnie, dlatego dnf install htop na nowej maszynie kończy się komunikatem No match for argument: htop, a następnie Error: Unable to find a match: htop. Nic nie jest uszkodzone i żaden mirror nie jest wyłączony. Podstawowa dystrybucja celowo dostarcza ograniczony zestaw pakietów, CRB jest obecne, ale wyłączone, a EPEL to oddzielne repozytorium społecznościowe, które należy dodać samodzielnie.

W systemie Ubuntu ten sam pakiet znajduje się w universe, a universe jest włączone w niemal każdym obrazie chmurowym, więc to pytanie nigdy się nie pojawia. Rodzina Red Hat dzieli pakiety inaczej i domyślnie oferuje ich mniej. Rozwiązanie wymaga trzech poleceń. Reszta tego przewodnika zawiera informacje, o których nikt nie wspomina w pierwszym tygodniu: co gwarantują te repozytoria, czego nie gwarantują oraz jak zapobiec sytuacji, w której repozytorium zewnętrznego dostawcy po cichu przejmuje kontrolę nad systemem bazowym.

Jak sprawdzono te polecenia. Nasze kontenery testowe działają wyłącznie na systemie Ubuntu, dlatego polecenia dnf poniżej nie zostały wykonane na naszych własnych maszynach testowych. Są one zgodne z dokumentacją Rocky Linux oraz AlmaLinux. Każdy krok wskazuje oczekiwany wynik, więc należy zweryfikować każdy z nich na własnym serwerze zamiast wklejać cały blok naraz.

Czym są BaseOS, AppStream oraz CRB?

BaseOS to sam system operacyjny: jądro, glibc, systemd oraz podstawowe narzędzia użytkownika. Wersje pakietów w tym repozytorium są zamrożone na cały okres wsparcia wydania głównego, a poprawki bezpieczeństwa są przenoszone (backportowane) do tych starszych wersji. Numer wersji w BaseOS, który wygląda na przestarzały, nie oznacza braku poprawek. Jest to wersja z zaaplikowanymi poprawkami, co stanowi istotę dystrybucji klasy enterprise.

AppStream zawiera oprogramowanie uruchamiane na systemie: serwery WWW, bazy danych, środowiska uruchomieniowe języków programowania, edytory oraz agenty monitorujące. W wersji 8 znaczna część AppStream była dostarczana jako moduły z alternatywnymi strumieniami, więc dnf module list miało znaczenie i wymagało wyboru, na przykład konkretnego strumienia PHP. Wersja 9 niemal całkowicie zrezygnowała z modularności, dlatego w Rocky 9 oraz Alma 9 zazwyczaj dostępna jest jedna wersja danego pakietu bez konieczności aktywacji modułu.

Extras jest domyślnie włączone i zawiera niewielką liczbę pakietów. Przechowuje głównie pakiety wydawnicze dla innych repozytoriów, z których pochodzi samo epel-release. Dzięki temu nie ma potrzeby korzystania z niepewnych adresów URL w celu instalacji EPEL w systemach Rocky lub Alma.

CRB to repozytorium CodeReady Builder, znane w wersji 8 jako PowerTools. Zawiera ono komponenty służące do budowania oprogramowania: nagłówki programistyczne, biblioteki statyczne oraz narzędzia testowe i dokumentację, które są wymagane podczas kompilacji pakietów. Repozytorium znajduje się na serwerach lustrzanych, ale jest domyślnie wyłączone. W produktach Red Hat ta sama zawartość nosi nazwę CodeReady Linux Builder, jest dostępna w ramach subskrypcji, jednak Red Hat zaznacza, że nie jest ona objęta wsparciem technicznym. Rocky oraz Alma dziedziczą zarówno zawartość, jak i domyślny stan wyłączenia.

Dla użytkowników przechodzących z systemów Debian lub Ubuntu: main łączy pakiety uruchomieniowe oraz nagłówki -dev w jednym archiwum, dlatego nie występuje tam odpowiednik CRB, który należałoby aktywować. Najbliższym odpowiednikiem EPEL jest universe, który jest utrzymywany przez społeczność i nie posiada gwarancji wsparcia ze strony dostawcy.

Czym jest EPEL i kto za nim stoi

EPEL to skrót od Extra Packages for Enterprise Linux. Jest to projekt społeczności Fedora: pakiety istniejące w Fedorze są przebudowywane dla aktualnego wydania korporacyjnego. Utrzymuje je grupa EPEL Special Interest Group, składająca się głównie z wolontariuszy ze społeczności Fedora. Red Hat udostępnia infrastrukturę budowania i mirrorowania, a niektórzy inżynierowie Red Hat utrzymują w nim wybrane pakiety. Na tym kończy się relacja. EPEL nie jest produktem Red Hat. Nie istnieje umowa wsparcia ani SLA (service level agreement) dla pakietów EPEL, zarówno w systemie RHEL, jak i jego klonach.

Jedna zasada sprawia, że włączenie EPEL jest bezpieczne: pakiet EPEL nigdy nie może zastąpić pakietu z podstawowej dystrybucji. Jeśli AppStream dostarcza nginx, EPEL tego nie zrobi. Zasada ta jest egzekwowana przez osoby recenzujące pakiety EPEL, więc dotyczy ona wyłącznie EPEL. Nie chroni ona przed niczym innym, co zostanie dodane później.

Obietnica dotycząca cyklu życia również różni się od tej dla podstawowej dystrybucji i to właśnie ten aspekt staje się problematyczny w trzecim roku eksploatacji. Wersja pakietu w BaseOS jest zamrożona na cały dziesięcioletni okres wsparcia wydania głównego. Utrzymujący pakiet EPEL deklaruje znacznie krótszy okres wsparcia: co najmniej jedno wydanie minor RHEL lub 13 miesięcy, zależnie od tego, co nastąpi wcześniej. W praktyce większość pakietów jest utrzymywana znacznie dłużej. Niektóre są wycofywane, gdy opiekun przestaje się nimi zajmować, a inne przeskakują na nową wersję główną w trakcie życia dystrybucji, ponieważ EPEL podąża za Fedorą. W rezultacie rutynowe dnf upgrade może dostarczyć nową wersję główną narzędzia z EPEL na maszynę, która miała być stabilna, a pakiet, od którego zależy działanie systemu, może przestać otrzymywać aktualizacje bez żadnego powiadomienia.

Warto znać jeszcze jedną konsekwencję przed włączeniem repozytorium: EPEL jest budowany w oparciu o najnowsze wydanie minor RHEL. Jeśli serwer jest utrzymywany w starszej wersji minor, przy użyciu zamrożonego mirrora lub repozytorium typu point release, pakiet EPEL może wymagać nowszej biblioteki systemowej niż ta dostępna w systemie. dnf zgłasza to jako brakującą zależność, co wygląda na problem z mirrorami, podczas gdy w rzeczywistości jest to problem rozbieżności wersji.

Włączanie CRB i instalacja EPEL w systemach Rocky lub 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

Polecenie dnf repolist --enabled powinno teraz wyświetlić baseos, appstream, extras, crb oraz epel. Może pojawić się również niewielki wpis epel-cisco-openh264, dodawany przez epel-release. Jeśli crb brakuje na tej liście, krok włączenia nie powiódł się; kolejna sekcja wyjaśnia przyczyny.

W systemach Rocky 8 oraz Alma 8 repozytorium nadal nosi nazwę PowerTools, dlatego środkowe polecenie przyjmuje postać sudo dnf config-manager --set-enabled powertools. Identyfikatory repozytoriów są rozróżniane pod kątem wielkości liter, a starsza dokumentacja CentOS 8 używa zapisu PowerTools z wielkimi literami, który nie zadziała. W systemie AlmaLinux 10 repozytorium CRB jest włączone domyślnie od wersji 10.0 (zmiana wprowadzona we wrześniu 2025 r.), więc w tym przypadku wymagany jest tylko krok epel-release.

Pakiet epel-release pochodzi z extras, który jest już włączony, więc nie ma potrzeby ręcznego ufania adresom URL ani importowania kluczy. Pakiet zapisuje /etc/yum.repos.d/epel.repo i instaluje klucz podpisu EPEL w lokalizacji /etc/pki/rpm-gpg/. Należy potwierdzić gpgcheck=1 w tym pliku i ignorować wszelkie poradniki zalecające obejście błędu podpisu za pomocą --nogpgcheck. Niepowodzenie weryfikacji podpisu oznacza, że pakiet nie jest tym, za co się podaje, lub że zegar systemowy jest nieprawidłowy.

W systemie Rocky polecenie epel-release instaluje również niewielkie narzędzie pomocnicze w /usr/bin/crb, dzięki czemu sudo crb enable oraz crb status wykonują to samo zadanie bez użycia wtyczki. Przed poleganiem na tym narzędziu należy sprawdzić jego obecność za pomocą command -v crb, ponieważ nie występuje ono w każdej gałęzi każdego systemu typu rebuild.

Aby sprawdzić, czy repozytorium EPEL jest osiągalne, a nie tylko widoczne na liście, należy wyszukać pakiet dostępny wyłącznie w tym źródle:

dnf repoquery --repo=epel htop

Polecenie to wyświetli nazwę pakietu, wersję oraz architekturę. Brak wyniku oznacza, że repozytorium jest włączone, ale nie zwraca danych, co zazwyczaj wynika z problemów z serwerem lustrzanym lub metadanymi, a nie z konfiguracji. W takim przypadku należy wykonać sudo dnf clean all && sudo dnf makecache.

Dlaczego dnf zgłasza błąd: no such command: config-manager

Jest to pierwszy problem, na który napotykają użytkownicy, występujący dokładnie w obrazach systemowych dostarczanych przez większość dostawców 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 jest wtyczką, a nie wbudowanym podpoleceniem dnf. Jest ona dostarczana w pakiecie dnf-plugins-core, który jest pobierany podczas pełnej instalacji serwera, ale pomijany w obrazach minimalnych, chmurowych oraz kontenerowych. Sugestia wyświetlana przez dnf działa, ponieważ pakiet deklaruje odpowiednią wirtualną możliwość:

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

Należy użyć cudzysłowu. Nawiasy są składnią powłoki, więc wersja bez cudzysłowu zakończy się błędem składni, a nie błędem dnf.

Jeśli instalacja wtyczki nie jest możliwa, ponieważ wymagane repozytorium jest wyłączone, należy edytować odpowiedni plik. Należy odnaleźć plik zawierający daną sekcję, otworzyć go i ustawić enabled=1 w sekcji [crb]:

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

Jest to dokładnie to, co zapisuje config-manager, więc ręczna edycja nie powoduje utraty funkcjonalności. Polecenie dnf repolist --enabled potwierdza wynik.

Niektóre pakiety EPEL nie zainstalują się bez włączonego CRB

Drugą częstą pułapką jest błąd, który w ogóle nie wspomina o CRB. Pakiet EPEL, który odwołuje się do biblioteki dostępnej tylko w repozytorium CRB, powoduje błąd podczas rozwiązywania zależności. Komunikat wskazuje wtedy nazwę biblioteki oraz pakietu, który jej wymaga:

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

Przyczyną jest wyłączone repozytorium CRB, przez co dnf nie widzi jedynego źródła, w którym znajduje się ta biblioteka. Należy sprawdzić dwie rzeczy w podanej kolejności:

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

Jeśli drugie polecenie wskazuje konkretny pakiet, a zwykła instalacja nadal kończy się niepowodzeniem, oznacza to, że CRB jest wyłączone. Ten typ błędu występuje na tyle często, że w wersji 10 systemu AlmaLinux włączono CRB domyślnie, aby wyeliminować ten problem. Flaga --enablerepo=crb również działa jako jednorazowe polecenie przy instalacji, jednak jeśli korzystasz z EPEL, pozostaw CRB włączone na stałe. Kolejna aktualizacja EPEL może wprowadzić nową zależność od CRB bez wcześniejszego ostrzeżenia.

Z jakiego repozytorium pochodzi ten pakiet?

Po kilku tygodniach pracy z czterema włączonymi repozytoriami, istotnym pytaniem przestaje być to, co jest zainstalowane, a staje się to, skąd dany pakiet pochodzi.

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 dla zainstalowanego pakietu wyświetla linię From repo. dnf list installed pokazuje te same informacje w trzeciej kolumnie z przedrostkiem @, więc @epel oznacza instalację z EPEL, a @System oznacza, że dnf nie posiada informacji o źródle, co zazwyczaj wskazuje na użycie rpm -i dla pobranego pliku. Linia repoquery podaje liczbę pakietów dla każdego repozytorium, co jest najszybszym sposobem na wykrycie, że przejęty serwer zawiera czterdzieści pakietów z repozytorium, o którym administrator nigdy nie słyszał. Ostatnie polecenie wyświetla dokładną listę pakietów dostarczonych przez konkretne repozytorium; ten spis jest niezbędny przed podjęciem decyzji o jego usunięciu.

Odpowiednikiem w systemie apt jest apt-cache policy <package>, a odpowiedniki poleceń dnf i apt warto mieć otwarte w drugiej karcie przez pierwszy miesiąc, ponieważ koncepcje te mapują się bezpośrednio, nawet jeśli flagi są odmienne.

Jak zapobiec zastępowaniu pakietów bazowych przez repozytoria firm trzecich?

EPEL gwarantuje, że nie będzie tego robić. Żadne inne repozytorium nie daje takiej obietnicy. Repozytorium dostawcy bazy danych, agenta lub środowiska uruchomieniowego może dostarczać własną wersję biblioteki, która jest już dostępna w BaseOS. Program dnf zainstaluje ją, ponieważ domyślna zasada dnf jest prosta: wygrywa najwyższa wersja, niezależnie od źródła.

Dwa parametry wykonują większość pracy; oba znajdują się w pliku repozytorium w sekcji /etc/yum.repos.d/.

priority= decyduje, które repozytorium wygrywa, gdy kilka z nich zawiera pakiet o tej samej nazwie. Niższe wartości wygrywają, a wartością domyślną jest 99. Należy zatem przypisać repozytoriom bazowym niską wartość, a repozytoriom firm trzecich wysoką. Wówczas dnf wybierze pakiet bazowy, nawet jeśli wersja z repozytorium zewnętrznego jest nowsza. Nowoczesny dnf obsługuje to samodzielnie, więc oddzielny pakiet yum-plugin-priorities z epoki CentOS 7 nie jest już częścią rozwiązania.

includepkgs= to silniejsza opcja filtrowania. excludepkgs= blokuje określone pakiety z repozytorium, co wymaga przewidzenia, co może ono dostarczyć. includepkgs= działa odwrotnie: repozytorium może dostarczać tylko wymienione nazwy i nic więcej. Repozytorium dostawcy, które powinno udostępniać wyłącznie własnego agenta, wymaga tylko jednej linii konfiguracji.

[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

W wersji 8 istnieje jeszcze jedno ustawienie, o którym warto wiedzieć. Pakiet z repozytorium zewnętrznego może być ukryty, gdy moduł AppStream dostarcza pakiet o tej samej nazwie, a module_hotfixes=1 w sekcji tego repozytorium nakazuje dnf zaprzestanie filtrowania. Jeśli pakiet jest widoczny dla dnf repoquery, ale nie instaluje się na systemie w wersji 8, zazwyczaj jest to przyczyna. Wersja 9 usunęła niemal wszystkie moduły, więc problem ten występuje tam rzadko.

Aby przypiąć pakiet do konkretnej wersji, należy zainstalować python3-dnf-plugin-versionlock i użyć sudo dnf versionlock add <package>. Jest to odpowiednik apt-mark hold. Należy zwrócić uwagę na różnicę, która często myli osoby przechodzące z systemu Debian: w apt wygrywa wyższy Pin-Priority, natomiast w dnf wygrywa niższy priority.

Dlaczego mieszanie repozytoriów pokrewnych RHEL uniemożliwia aktualizację serwera

Rocky, Alma, CentOS Stream, Oracle Linux oraz RHEL są na tyle zbliżone, że ich pakiety dają się instalować zamiennie, lecz jednocześnie na tyle odmienne, że wynikowy system staje się niemożliwy do wspierania.

Mechanizm ten opiera się na numerach wersji. CentOS Stream 9 wyprzedza RHEL 9, więc wskazanie systemu Rocky 9 na repozytorium Stream, nawet jednorazowo i dla pojedynczego pakietu, powoduje zainstalowanie wersji wyższych niż te, które kiedykolwiek zostaną wydane w Rocky. Gdy pojawi się kolejne wydanie minor Rocky, wersja posiadanego pakietu będzie wyższa niż w oficjalnym repozytorium, więc dnf upgrade pominie go podczas aktualizacji. Maszyna pracuje wówczas w konfiguracji, której nikt nie testował, a stan ten może trwać latami, podczas gdy administrator zakłada, że system jest poprawiony.

Objawem jest sytuacja, w której dnf upgrade nie zgłasza żadnych zadań, podczas gdy sudo dnf distro-sync sugeruje obniżenie wersji (downgrade) długiej listy pakietów. Narzędziem naprawczym jest distro-sync: wymusza ono, aby każdy zainstalowany pakiet odpowiadał wersji dostępnej w aktywnych repozytoriach, włącznie z obniżeniem wersji. Należy najpierw wyłączyć obce repozytorium, następnie uruchomić polecenie i dokładnie przejrzeć listę zmian przed jej zaakceptowaniem. Naprawa kończy się niepowodzeniem, gdy starszy pakiet RPM nie jest już dostępny na serwerze lustrzanym; w takim przypadku odtworzenie serwera z czystego obrazu jest szybsze i bezpieczniejsze niż walka z mechanizmem rozwiązywania zależności.

Pozostałości z ery ELevate to inny częsty wariant tego problemu. ELevate to narzędzie migracyjne AlmaLinux oparte na Leapp, używane do przenoszenia systemu CentOS 7 lub konwersji między różnymi dystrybucjami typu rebuild. Pośpiesznie przeprowadzona migracja pozostawia pliki repozytoriów EL7 w /etc/yum.repos.d/ oraz zainstalowane pakiety EL7. Można je odnaleźć za pomocą rpm -qa | grep el7. Każdy z nich to pakiet, którego żadne aktywne repozytorium nie będzie w stanie zaktualizować, a późniejsze uruchomienie Leapp zgłosi je jako pakiety niemożliwe do zmapowania, co stanie się blokadą aktualizacji wymagającą ręcznego usunięcia. Należy je usunąć, gdy serwer pracuje stabilnie, a nie w dniu, w którym konieczne jest przeprowadzenie kolejnej dużej aktualizacji.

Repozytorium dostawcy przesłaniające pakiet z AppStream to łagodna wersja tego samego problemu, a linia includepkgs powyżej stanowi rozwiązanie. Dotyczy to zazwyczaj narzędzi kontenerowych, ponieważ containerd.io z własnego repozytorium Docker wchodzi w konflikt z runc z AppStream, więc jeden z nich musi zostać usunięty. Należy podjąć decyzję, zapisać wykluczenie i przestrzegać sprawdzonej kolejności: instrukcja instalacji Docker na Rocky Linux opisuje, które pakiety dystrybucyjne należy usunąć w pierwszej kolejności.

Przejście z apt na dnf w kontekście repozytoriów

• /etc/apt/sources.list.d/*.sources staje się /etc/yum.repos.d/*.repo, gdzie jeden plik może zawierać kilka [sections], każdą z własnym identyfikatorem.
• add-apt-repository universe staje się dnf install epel-release, z tą różnicą, że universe nadal znajduje się wewnątrz archiwum Ubuntu, a EPEL jest oddzielnym projektem.
• apt update nie posiada odpowiednika, o czym należy pamiętać. dnf odświeża metadane według własnego harmonogramu, a dnf makecache wymusza to natychmiast.
• apt-cache policy <pkg> staje się dnf info <pkg>, dodatkowo dnf list --showduplicates <pkg> pozwala wyświetlić każdą dostępną wersję.
• apt-mark hold staje się dnf versionlock add, z python3-dnf-plugin-versionlock.
• Pinning w /etc/apt/preferences.d/ staje się priority= w sekcji repozytorium, przy czym wartości liczbowe działają w odwrotnym kierunku.
• dpkg -S /path/to/file staje się rpm -qf /path/to/file.

Automatyczne aktualizacje przenoszone są jako koncepcja, a nie składnia, ponieważ nie ma tutaj unattended-upgrades. Timer, plik konfiguracyjny oraz kwestia wymaganego restartu zostały omówione w dnf-automatic w systemach Rocky i Alma.

Ograniczanie liczby repozytoriów

Włącz CRB, zainstaluj epel-release, a następnie odnotuj wykonane czynności oraz ich uzasadnienie w systemie zarządzania konfiguracją lub w pliku tekstowym na serwerze. Taka notatka jest niezwykle cenna, gdy serwer ma trzy lata i jest obsługiwany przez inną osobę.

Przeszukaj zasoby przed dodaniem nowych. Uruchom dnf search, następnie dnf info i dopiero wtedy rozważ dodanie nowego repozytorium. Zaskakująco wiele pakietów, dla których użytkownicy włączają EPEL, znajduje się już w AppStream. Monitorowanie systemu jest tego najlepszym przykładem, ponieważ Performance Co-Pilot jest dostępny w podstawowych repozytoriach i nie wymaga żadnych zewnętrznych źródeł. Każde dodatkowe repozytorium to kolejny podmiot, który może dostarczyć pakiet w dowolnym momencie, co utrudnia każdą kolejną dużą aktualizację systemu.

Jeśli nadal wybierasz między tymi dwiema dystrybucjami, pamiętaj, że cały układ jest w obu identyczny, a epel-release działa w ten sam sposób. Rzeczywiste różnice leżą gdzie indziej: porównanie Rocky Linux i AlmaLinux omawia filozofię przebudowy systemu, ponieważ AlmaLinux obecnie koncentruje się na kompatybilności ABI (application binary interface), a nie na wiernym odtwarzaniu kodu linia po linii.

FAQ

Jak włączyć EPEL w systemie Rocky Linux 9 lub AlmaLinux 9?

Uruchom sudo dnf install -y dnf-plugins-core, następnie sudo dnf config-manager --set-enabled crb, a potem sudo dnf install -y epel-release. Potwierdź za pomocą dnf repolist --enabled, co powinno wyświetlić baseos, appstream, extras, crb oraz epel. Włącz CRB przed instalacją pakietów EPEL, ponieważ wiele z nich zależy od bibliotek dostępnych wyłącznie w CRB. W wersji 8 identyfikator repozytorium to powertools zamiast crb.

Czy włączanie EPEL na serwerze produkcyjnym jest bezpieczne?

Jest to rozwiązanie powszechnie stosowane, oparte na zasadzie, że pakiety EPEL nigdy nie zastępują pakietów z dystrybucji bazowej, więc włączenie repozytorium nie zmienia zawartości BaseOS ani AppStream. Zastrzeżenie dotyczy wsparcia: EPEL to projekt społeczności Fedora bez gwarantowanego poziomu usług (SLA), a opiekun pakietu zobowiązuje się do jego utrzymania przez okres nawet jednego wydania minor RHEL lub 13 miesięcy. Prowadź inwentaryzację za pomocą dnf repository-packages epel list installed i używaj dnf versionlock dla każdego pakietu EPEL, od którego zależy usługa wystawiona na zewnątrz.

Dlaczego dnf zgłasza błąd: no such command: config-manager?

Ponieważ config-manager jest wtyczką dnf, a nie wbudowanym poleceniem, a obrazy minimalne lub kontenerowe są dostarczane bez dnf-plugins-core. Komunikat błędu wskazuje rozwiązanie: sudo dnf install -y 'dnf-command(config-manager)' (w cudzysłowie, aby powłoka nie interpretowała nawiasów). Jeśli instalacja nie jest jeszcze możliwa, uruchom grep -rl crb /etc/yum.repos.d/, otwórz wskazany plik i ustaw enabled=1 w sekcji [crb] ręcznie.

Jaka jest różnica między CRB a PowerTools?

To to samo repozytorium pod dwiema nazwami. Wersja 8 nazywa je PowerTools z identyfikatorem powertools, wersja 9 i nowsze nazywają je CRB z identyfikatorem crb, a produkt Red Hat określa tę zawartość jako CodeReady Linux Builder. Zawiera ono nagłówki programistyczne, biblioteki statyczne oraz narzędzia do budowania i jest domyślnie wyłączone w systemach Rocky oraz AlmaLinux 9. AlmaLinux 10 włącza je domyślnie od wersji 10.0, więc sprawdź dnf repolist --enabled przed uruchomieniem polecenia włączającego w tej wersji.

Jak usunąć EPEL bez powodowania awarii systemu?

Najpierw sporządź inwentaryzację za pomocą dnf repository-packages epel list installed, ponieważ usunięcie samego pakietu epel-release nie usuwa zależności zainstalowanych z EPEL. Pakiety te pozostają na dysku, tracą źródło aktualizacji i przestają otrzymywać poprawki bezpieczeństwa bez żadnego powiadomienia. Podejmij decyzję dla każdego pakietu z osobna, usuń lub zastąp te, które nie są już potrzebne, a dopiero potem uruchom sudo dnf remove epel-release. Jeśli coś z EPEL nie zastąpiło żadnego pakietu systemowego i musi zostać usunięte, sudo dnf repository-packages epel remove wyczyści zestaw w jednej transakcji, więc dokładnie przejrzyj proponowaną listę przed jej zatwierdzeniem.