Rocky Linux ve AlmaLinux EPEL ve CRB Depoları Kurulumu

dnf neden istediğiniz paketi bulamıyor

EPEL ve CRB, yeni kurulmuş bir Rocky Linux veya AlmaLinux sunucusunda varsayılan olarak sunulmayan iki depodur; bu nedenle yeni bir makinede dnf install htop komutu No match for argument: htop yanıtını verir ve ardından Error: Unable to find a match: htop hatası alınır. Sistemde bir arıza yoktur ve hiçbir yansıma (mirror) sunucusu kapalı değildir. Temel dağıtım, paketlerin küçük bir kısmını bilinçli olarak sunar; CRB yüklü gelir ancak kapalıdır, EPEL ise ayrıca eklemeniz gereken bir topluluk deposudur.

Ubuntu üzerinde aynı paket universe içerisinde yer alır ve universe neredeyse tüm bulut imajlarında etkinleştirilmiş durumdadır; bu yüzden bu soru hiç gündeme gelmez. Red Hat ailesi paketlerini farklı şekilde bölümlendirir ve varsayılan olarak daha az paket sunar. Çözüm üç komuttan ibarettir. Bu kılavuzun geri kalanı, ilk haftada kimsenin size söylemediği kısımdır: bu depoların ne vaat ettiği, neyi vaat etmediği ve üçüncü taraf bir deponun temel sisteminizi sessizce ele geçirmesini nasıl engelleyeceğiniz.

Bu komutlar nasıl kontrol edildi. Komut test container'larımız yalnızca Ubuntu çalıştırdığı için aşağıdaki dnf komutları kendi test makinelerimizde çalıştırılmamıştır. Bu komutlar, Rocky Linux ve AlmaLinux dokümantasyonuna dayanmaktadır. Her adım görmeniz gereken çıktıyı belirtir, bu nedenle tüm bloğu tek seferde yapıştırmak yerine her birini kendi sunucunuzda kontrol edin.

BaseOS, AppStream ve CRB nedir?

BaseOS, işletim sisteminin kendisidir: çekirdek, glibc, systemd ve temel kullanıcı alanı araçları. Buradaki sürümler, ana sürümün yaşam döngüsü boyunca dondurulur ve güvenlik yamaları bu dondurulmuş sürümlere geriye dönük olarak uygulanır (backport). BaseOS içinde yıllar öncesine ait gibi görünen bir sürüm numarası, paketin yamalanmadığı anlamına gelmez. Bu, kurumsal bir dağıtımın temel amacı olan, yamalanmış eski bir sürümdür.

AppStream, üzerinde çalıştırdığınız bileşenleri barındırır: web sunucuları, veritabanları, dil çalışma zamanları, düzenleyiciler ve izleme ajanları. Sürüm 8'de AppStream'in büyük bir kısmı alternatif akışlara sahip modüller olarak sunuluyordu; bu nedenle dnf module list önemliydi ve örneğin tek bir PHP akışı seçmeniz gerekiyordu. Sürüm 9'da modülerlik neredeyse tamamen kaldırıldı; bu yüzden Rocky 9 ve Alma 9 üzerinde genellikle bir şeyin tek bir sürümü sunulur ve önce etkinleştirilmesi gereken bir modül bulunmaz.

Extras varsayılan olarak etkindir ve oldukça küçüktür. Çoğunlukla diğer depolar için sürüm paketlerini barındırır; epel-release de buradan gelir. Bu detay, Rocky veya Alma üzerinde EPEL kurmak için rastgele bir URL'ye güvenmenize asla gerek kalmamasının nedenidir.

CRB, sürüm 8'de PowerTools olarak adlandırılan CodeReady Builder deposudur. Dağıtımın geliştirme tarafını barındırır: geliştirme başlıkları (headers), statik kütüphaneler ile paketlerin derleme zamanında ihtiyaç duyduğu test ve dokümantasyon araçları. Bu depo aynalarda (mirror) halihazırda mevcuttur ancak varsayılan olarak devre dışıdır. Red Hat'in kendi ürününde aynı içerik CodeReady Linux Builder olarak adlandırılır, abonelikle birlikte gelir ve Red Hat bu içeriğin destek kapsamında olmadığını belirtir. Rocky ve Alma, hem içeriği hem de varsayılan olarak devre dışı olma durumunu devralır.

Debian veya Ubuntu'dan gelen okuyucular için: main, çalışma zamanı paketlerini ve -dev başlıklarını tek bir arşivde harmanlar; bu nedenle orada etkinleştirilecek bir CRB yoktur. EPEL'in en yakın karşılığı, topluluk tarafından sürdürülen ve herhangi bir satıcı destek taahhüdü taşımayan universe'dur.

EPEL nedir ve arkasında kim vardır

EPEL, Extra Packages for Enterprise Linux (Kurumsal Linux için Ek Paketler) ifadesinin kısaltmasıdır. Bu bir Fedora projesidir: Fedora'da bulunan paketler, mevcut kurumsal sürüm için yeniden derlenir ve çoğunluğu Fedora topluluğundan gönüllülerden oluşan EPEL Özel İlgi Grubu (Special Interest Group) tarafından yönetilir. Red Hat, derleme ve yansıma altyapısını barındırır; bazı Red Hat mühendisleri de paketlerin bakımını yapar. İlişki burada sona erer. EPEL bir Red Hat ürünü değildir. RHEL veya yeniden derlenmiş sürümler üzerinde, bir EPEL paketi için destek sözleşmesi veya SLA (hizmet seviyesi anlaşması) bulunmaz.

EPEL'in etkinleştirilmesini güvenli kılan tek bir politika vardır: Bir EPEL paketi, temel dağıtımdan gelen bir paketin yerini asla alamaz. Eğer AppStream nginx paketini sunuyorsa, EPEL sunmayacaktır. Bu kural, EPEL paketlerini inceleyen kişiler tarafından uygulanır; dolayısıyla bu sadece EPEL ile ilgili bir taahhüttür. Sizi daha sonra eklediğiniz diğer hiçbir şeyden korumaz.

Yaşam döngüsü taahhüdü de temel dağıtımdan farklıdır ve üçüncü yılda sorun yaratan kısım budur. Bir BaseOS paket sürümü, ana sürümün on yıllık ömrü boyunca dondurulur. Bir EPEL paket sorumlusu ise çok daha kısa bir süre için taahhütte bulunur: en az bir RHEL ara sürümü veya 13 ay (hangisi daha kısaysa). Uygulamada çoğu paket bundan çok daha uzun süre korunur. Bazıları paket sorumlusu ayrıldığında kullanımdan kaldırılır, bazıları ise EPEL Fedora'yı takip ettiği için dağıtımınızın ömrünün ortasında yeni bir ana sürüme geçer. Bu nedenle rutin bir dnf upgrade işlemi, kararlı olduğunu düşündüğünüz bir makinede bir EPEL aracının yeni bir ana sürümünü size sunabilir ve bağımlı olduğunuz bir paket, size ulaşan herhangi bir duyuru olmaksızın güncelleme almayı durdurabilir.

Etkinleştirmeden önce bilinmesi gereken bir sonuç daha vardır: EPEL, en yeni RHEL ara sürümüne göre derlenir. Eğer bir sunucuyu dondurulmuş bir yansıma veya satıcıya özel bir sürüm deposu kullanarak daha eski bir ara sürümde tutuyorsanız, bir EPEL paketi elinizdekinden daha yeni bir temel kütüphaneye ihtiyaç duyabilir. dnf bunu eksik bir bağımlılık olarak raporlar; bu durum aslında bir sürüm uyumsuzluğu sorunu olmasına rağmen bir yansıma sorunu gibi görünür.

Rocky veya Alma üzerinde CRB'yi etkinleştirme ve EPEL kurma

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 komutu artık baseos, appstream, extras, crb ve epel listesini göstermelidir. Ayrıca epel-release tarafından eklenen küçük bir epel-cisco-openh264 girdisi de görebilirsiniz. Eğer crb bu listede yoksa, etkinleştirme adımı gerçekleşmemiştir; bir sonraki bölüm bunun nedenini açıklamaktadır.

Rocky 8 ve Alma 8 üzerinde depo hala PowerTools olarak adlandırılmaktadır, bu nedenle orta komut sudo dnf config-manager --set-enabled powertools halini alır. Depo kimlikleri büyük/küçük harfe duyarlıdır ve eski CentOS 8 belgeleri bunu büyük harflerle PowerTools olarak yazar; bu durum eşleşme sağlamayacaktır. AlmaLinux 10 üzerinde CRB deposu 10.0 sürümünden itibaren (Eylül 2025'te değiştirilmiştir) varsayılan olarak etkindir, bu nedenle orada yalnızca epel-release adımını uygulamanız yeterlidir.

epel-release, halihazırda etkin olan extras kaynağından gelir, bu nedenle güvenilecek bir URL veya elle içe aktarılacak bir anahtar yoktur. Paket, /etc/yum.repos.d/epel.repo dosyasını yazar ve EPEL imzalama anahtarını /etc/pki/rpm-gpg/ altına kurar. Bu dosya içindeki gpgcheck=1 değerini doğrulayın ve imza hatasını --nogpgcheck ile aşmanızı söyleyen hiçbir kılavuzu dikkate almayın. Başarısız bir imza denetimi, paketin iddia edildiği gibi olmadığını veya sistem saatinizin yanlış olduğunu gösterir.

Rocky üzerinde epel-release, /usr/bin/crb konumuna küçük bir yardımcı araç da kurar, bu nedenle sudo crb enable ve crb status eklenti olmaksızın aynı işi yapar. Buna güvenmeden önce command -v crb ile mevcut olup olmadığını kontrol edin, çünkü her yeniden yapılandırma dalında bulunmayabilir.

EPEL'in yalnızca listelenmekle kalmayıp erişilebilir olduğunu kanıtlamak için, yalnızca EPEL'de bulunan bir paketi sorgulayın:

dnf repoquery --repo=epel htop

Bu komut paket adını, sürümünü ve mimarisini yazdırır. Sessizlik, deponun etkin olduğunu ancak sonuç döndürmediğini gösterir; bu genellikle bir yapılandırma sorunundan ziyade bir yansıma (mirror) veya meta veri sorunudur, bu nedenle bir sonraki adımda sudo dnf clean all && sudo dnf makecache komutunu deneyin.

Neden dnf, config-manager komutunun bulunamadığını söylüyor?

Bu durum, kullanıcıların karşılaştığı ilk engeldir ve tam olarak çoğu VPS sağlayıcısının sunduğu imajlarda yaşanır.

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 bir eklentidir, dnf'in yerleşik bir alt komutu değildir. Tam bir sunucu kurulumunda otomatik olarak gelen ancak minimal imajlarda, bulut imajlarında ve container imajlarında dahil edilmeyen dnf-plugins-core paketi içerisinde yer alır. dnf'in kendi önerisi işe yarar çünkü paket bu sanal yeteneği tanımlar:

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

Komutu tırnak içine alın. Parantezler shell sözdizimine aittir; bu nedenle tırnak kullanılmayan bir sürüm, dnf hatası yerine sözdizimi hatası vererek başarısız olur.

Eğer ihtiyacınız olan depo devre dışı bırakılmış olduğu için eklentiyi kuramıyorsanız, bunun yerine ilgili dosyayı düzenleyin. Hangi dosyanın ilgili bölümü içerdiğini bulun, dosyayı açın ve [crb] altında enabled=1 değerini ayarlayın:

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

Bu işlem, config-manager komutunun yaptığı işlemin aynısıdır; dolayısıyla manuel olarak yapıldığında hiçbir veri kaybı yaşanmaz. dnf repolist --enabled komutu sonucu doğrular.

Bazı EPEL paketleri CRB etkinleştirilmeden kurulamaz

İkinci yaygın tuzak, CRB'den hiç bahsetmeyen bir hata verir. Yalnızca CRB içinde sunulan bir kütüphaneye bağımlı olan bir EPEL paketi, bağımlılık çözümleme sırasında başarısız olur ve hata mesajı, kütüphanenin adını ve onu talep eden paketi belirtir:

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

Bunun nedeni CRB'nin devre dışı olmasıdır; bu nedenle dnf, söz konusu kütüphaneyi sağlayan tek depoyu göremez. Şu iki adımı sırasıyla kontrol edin:

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

Eğer ikinci komut bir paket adı döndürürken standart kurulum hala başarısız oluyorsa, CRB kapalıdır. Bu hata türü o kadar yaygındır ki AlmaLinux, bu durumun yaşanmasını engellemek için 10. sürümde CRB'yi varsayılan olarak açık hale getirmiştir. --enablerepo=crb tek seferlik bir kurulumda bayrak olarak da kullanılabilir; ancak EPEL kullanıyorsanız CRB'yi kalıcı olarak etkin bırakın. Çünkü bir sonraki EPEL güncellemesi, sizi önceden uyarmadan yeni bir CRB bağımlılığı getirebilir.

Bu paket hangi depodan geldi?

Dört deponun etkin olduğu birkaç haftalık kullanımdan sonra, asıl önemli soru neyin yüklü olduğu değil, nereden geldiğidir.

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 komutu, yüklü bir paket üzerinde çalıştırıldığında bir From repo satırı yazdırır. dnf list installed, aynı bilgiyi üçüncü sütunda başında @ olacak şekilde gösterir; bu nedenle @epel, paketin EPEL üzerinden yüklendiği anlamına gelir. @System ise dnf'in paketin kaynağını bilmediğini gösterir; bu durum genellikle birinin indirilen bir dosya üzerinde rpm -i komutunu çalıştırdığı anlamına gelir. repoquery satırı, depo başına paket sayısını verir; bu, devraldığınız bir sunucuda daha önce hiç duymadığınız bir depodan gelen kırk paket olduğunu keşfetmenin en hızlı yoludur. Son komut, tek bir deponun size tam olarak ne sağladığını listeler; bir depoyu kaldırmaya karar vermeden önce bu envantere ihtiyacınız vardır.

Buradaki apt alışkanlığı apt-cache policy <package> komutudur ve dnf ve apt komut eşdeğerleri, ilk ay boyunca ikinci bir sekmede açık tutulmaya değerdir; çünkü bayraklar uyuşmasa bile kavramlar birbirine net bir şekilde karşılık gelir.

Üçüncü taraf bir deponun temel bir paketi değiştirmesini nasıl engellerim?

EPEL bunu yapmayacağını taahhüt eder. Başka hiçbir depo bu garantiyi vermez. Bir veritabanı, aracı veya dil çalışma zamanı için sunulan bir satıcı deposu, BaseOS'in de sağladığı bir kütüphanenin kendi sürümünü dağıtabilir. dnf bunu kuracaktır çünkü dnf'in varsayılan kuralı basittir: nereden gelirse gelsin, en yüksek sürüm numarasına sahip paket kazanır.

İki kontrol mekanizması işin büyük kısmını halleder ve her ikisi de /etc/yum.repos.d/ altındaki depo dosyasında bulunur.

priority=, aynı paket ismini birden fazla depo taşıdığında hangi deponun kazanacağına karar verir. Düşük sayılar kazanır ve varsayılan değer 99'dur; bu nedenle temel depolarınıza düşük bir sayı, üçüncü taraf depolara ise yüksek bir sayı verin. Böylece dnf, üçüncü taraf sürümü daha yeni olsa bile temel paketi tercih eder. Modern dnf bunu kendi başına yönetir, bu yüzden CentOS 7 döneminin ayrı yum-plugin-priorities paketi artık çözümün bir parçası değildir.

includepkgs=, filtreleme seçenekleri arasında daha güçlü olanıdır. excludepkgs=, belirli paketlerin bir depodan çekilmesini engeller; bu, deponun ne dağıtabileceğini tahmin etmenizi gerektirir. includepkgs= ise bunu tersine çevirir: bu depo yalnızca belirtilen isimleri sağlayabilir, başka hiçbir şeyi sağlayamaz. Yalnızca kendi aracını sunması gereken bir satıcı deposu için bu tek satırlık bir işlemdir.

[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

Sürüm 8'de bilinmesi gereken bir ayar daha vardır. Üçüncü taraf bir depodan gelen bir paket, bir AppStream modülü aynı ismi sağladığında gizlenebilir; ilgili depo bölümündeki module_hotfixes=1 ayarı, dnf'e bu filtrelemeyi durdurmasını söyler. Eğer bir paket dnf repoquery tarafından görülebiliyor ancak bir 8 sistemine kurulamıyorsa, bunun nedeni genellikle budur. Sürüm 9 neredeyse tüm modülleri kaldırdığı için bu durum orada nadiren görülür.

Bir paketi belirli bir sürüme sabitlemek için python3-dnf-plugin-versionlock paketini kurun ve sudo dnf versionlock add <package> kullanın. Bu, apt-mark hold ile eşdeğerdir. Debian'dan gelenleri şaşırtan bir terslik olduğunu unutmayın: apt içinde daha yüksek bir Pin-Priority kazanırken, dnf içinde daha düşük bir priority kazanır.

RHEL tabanlı depoları karıştırmak bir sunucuyu neden yükseltilemez hale getirir

Rocky, Alma, CentOS Stream, Oracle Linux ve RHEL birbirlerine paketlerin karşılıklı yüklenebileceği kadar yakın, ancak sonuçta kimsenin destekleyemeyeceği bir sistem oluşturacak kadar uzaktır.

Bunun temel nedeni sürüm numaralarıdır. CentOS Stream 9, RHEL 9'un ilerisinde çalışır. Bu nedenle, bir Rocky 9 sunucusunu tek bir paket için bile olsa bir Stream deposuna yönlendirmek, Rocky'nin hiçbir zaman sunmayacağı kadar yüksek sürüm numaralı paketlere sahip olmanıza neden olur. Bir sonraki Rocky ara sürümü yayınlandığında, o paketin sürümü sizinkinden daha düşük kalacağı için dnf upgrade pakete dokunmayacaktır. Makine artık kimsenin test etmediği bir kombinasyonla çalışır ve siz sistemin yamalı olduğunu varsayarken, bu durum yıllarca sessizce devam eder.

Bunun belirtisi, dnf upgrade komutunun yapılacak bir işlem olmadığını bildirmesi, ancak sudo dnf distro-sync komutunun uzun bir paket listesini düşürmeyi (downgrade) önermesidir. distro-sync bu noktada onarım aracıdır: yüklü olan her paketi, düşürmeler dahil olmak üzere, etkinleştirilmiş depolarda sunulan sürümlerle eşleşmeye zorlar. Önce yabancı depoyu devre dışı bırakın, ardından komutu çalıştırın ve onaylamadan önce önerilen listeyi inceleyin. Eski RPM paketi yansıda (mirror) artık bulunmadığında onarım başarısız olur; bu noktada sunucuyu temiz bir imajdan yeniden kurmak, bağımlılık çözücüyle uğraşmaktan daha hızlı ve güvenlidir.

ELevate döneminden kalan kalıntılar, bu sorunun diğer yaygın biçimidir. ELevate, bir CentOS 7 sunucusunu ileri taşımak veya dağıtımlar arası geçiş yapmak için Leapp üzerine inşa edilmiş bir AlmaLinux taşıma aracıdır. Aceleye getirilmiş bir taşıma işlemi, /etc/yum.repos.d/ dizininde EL7 depo dosyalarının ve sistemde EL7 paketlerinin kalmasına neden olur. Bunları rpm -qa | grep el7 ile bulun. Bunların her biri, etkinleştirilmiş hiçbir deponun güncelleyemeyeceği paketlerdir ve sonraki bir Leapp çalışması bunları eşleyemediği paketler olarak raporlar; bu da elle temizlemeniz gereken bir yükseltme engelleyicisine dönüşür. Bunları, bir sonraki büyük yükseltmeye ihtiyaç duyduğunuz gün değil, sunucu sakin durumdayken temizleyin.

Bir satıcı deposunun AppStream paketini gölgelemesi, aynı sorunun hafif bir versiyonudur ve yukarıdaki includepkgs satırı bunun çözümüdür. Konteyner araçları genellikle bu duruma neden olur; çünkü Docker'ın kendi deposundan gelen containerd.io, AppStream'deki runc ile çakışır ve bunlardan birinin gitmesi gerekir. Bir kez karar verin, dışlama kuralını yazın ve bilinen doğru bir sırayı takip edin: Rocky Linux üzerinde Docker kurulumu kılavuzu, önce hangi dağıtım paketlerinin kaldırılması gerektiğini açıklar.

Depolar için apt'den dnf'e geçiş

• /etc/apt/sources.list.d/*.sources yerini /etc/yum.repos.d/*.repo alır; burada tek bir dosya, her biri kendi kimliğine sahip birden fazla [sections] barındırabilir.
• add-apt-repository universe yerini dnf install epel-release alır; aradaki fark, universe'un hala Ubuntu'nun kendi arşivinde bulunması, EPEL'in ise ayrı bir proje olmasıdır.
• apt update'ın doğrudan bir karşılığı yoktur, bunu hatırlamanız gerekir. dnf meta verileri kendi zamanlamasına göre yeniler, dnf makecache ise bunu hemen yapmaya zorlar.
• apt-cache policy <pkg> yerini dnf info <pkg> alır; sunulan tüm sürümleri görmek için dnf list --showduplicates <pkg> eklenir.
• apt-mark hold yerini dnf versionlock add alır; bu işlem python3-dnf-plugin-versionlock üzerinden gerçekleştirilir.
• /etc/apt/preferences.d/ içindeki sabitleme (pinning), depo bölümünde priority= haline gelir; burada sayılar ters yönde işler.
• dpkg -S /path/to/file yerini rpm -qf /path/to/file alır.

Otomatik güncellemeler, söz diziminden ziyade bir mantık olarak aktarılır çünkü burada unattended-upgrades bulunmamaktadır. Zamanlayıcı, yapılandırma dosyası ve yeniden başlatma gerekliliği gibi konular Rocky ve Alma üzerinde dnf-automatic başlığında ele alınmıştır.

Depo listesini kısa tutun

CRB'yi etkinleştirin, epel-release paketini kurun ve ardından yaptıklarınızı ve nedenlerini, yapılandırma yönetimi aracınıza veya sunucu üzerinde düz bir metin dosyasına not edin. Sunucu üç yıllık olduğunda ve yönetimi başka birine geçtiğinde, bu notun değeri tahmin ettiğinizden çok daha fazladır.

Yeni bir depo eklemeden önce arama yapın. dnf search komutunu, ardından dnf info komutunu çalıştırın; ancak bu işlemlerden sonra yeni bir depo eklemeyi düşünün. İnsanların EPEL'i etkinleştirme nedenlerinin şaşırtıcı bir kısmı zaten AppStream içinde mevcuttur. Sistem izleme bunun en net örneğidir; Performance Co-Pilot temel depolarda yer alır ve herhangi bir üçüncü taraf yazılıma ihtiyaç duymaz. Eklenen her yeni depo, size herhangi bir Salı günü paket gönderebilecek yeni bir taraf demektir ve her biri bir sonraki büyük sürüm yükseltmesini daha zor hale getirir.

Eğer hala iki dağıtım arasında seçim yapıyorsanız, bu yapılandırmanın her ikisinde de aynı olduğunu ve epel-release aracının özdeş şekilde çalıştığını bilmelisiniz. Asıl farklar başka yerlerdedir: Rocky Linux ve AlmaLinux karşılaştırması, AlmaLinux'un artık birebir yeniden derleme yerine ABI (uygulama ikili arayüzü) uyumluluğunu hedeflemesi nedeniyle yeniden derleme felsefesini ele almaktadır.

FAQ

Rocky Linux 9 veya AlmaLinux 9 üzerinde EPEL nasıl etkinleştirilir?

Sırasıyla sudo dnf install -y dnf-plugins-core, sudo dnf config-manager --set-enabled crb ve sudo dnf install -y epel-release komutlarını çalıştırın. baseos, appstream, extras, crb ve epel öğelerini listelemesi gereken dnf repolist --enabled komutu ile doğrulamayı yapın. EPEL paketlerini kurmadan önce CRB'yi etkinleştirin; çünkü bu paketlerin birçoğu yalnızca CRB tarafından sağlanan kütüphanelere bağımlıdır. Sürüm 8 üzerinde depo kimliği crb yerine powertools şeklindedir.

Üretim sunucusunda EPEL'i etkinleştirmek güvenli midir?

Yaygın olarak kullanılır ve EPEL paketlerinin temel dağıtımdaki paketlerin yerini asla almaması ilkesi üzerine kuruludur; bu nedenle etkinleştirilmesi BaseOS veya AppStream tarafından sağlananları değiştirmez. Dikkat edilmesi gereken nokta destektir: EPEL, hizmet seviyesi anlaşması (SLA) olmayan gönüllü bir Fedora projesidir ve bir paket sorumlusu, paketi en az bir RHEL ara sürümü veya 13 ay boyunca desteklemeyi taahhüt eder. dnf repository-packages epel list installed ile bir envanter tutun ve müşteri odaklı bir servisin bağımlı olduğu tüm EPEL paketleri için dnf versionlock kullanın.

dnf neden "no such command: config-manager" hatası veriyor?

Çünkü config-manager yerleşik bir komut değil, bir dnf eklentisidir ve minimal veya container imajları dnf-plugins-core olmadan gelir. Hata mesajının kendisi çözümü sunar: Kabuğun parantezleri okumaması için tırnak içinde sudo dnf install -y 'dnf-command(config-manager)' komutunu çalıştırın. Henüz hiçbir şey kuramıyorsanız, grep -rl crb /etc/yum.repos.d/ komutunu çalıştırın, belirttiği dosyayı açın ve [crb] bölümündeki enabled=1 değerini manuel olarak ayarlayın.

CRB ve PowerTools arasındaki fark nedir?

Bunlar aynı deponun iki farklı ismidir. Sürüm 8, powertools kimliği ile PowerTools olarak adlandırırken, sürüm 9 ve sonrası crb kimliği ile CRB olarak adlandırır; Red Hat'in kendi ürünü ise bu içeriği CodeReady Linux Builder olarak adlandırır. Geliştirme başlıklarını, statik kütüphaneleri ve derleme zamanı araçlarını içerir; Rocky ve AlmaLinux 9 üzerinde varsayılan olarak devre dışıdır. AlmaLinux 10, 10.0 sürümünden itibaren bunu varsayılan olarak etkinleştirir, bu nedenle orada etkinleştirme komutunu çalıştırmadan önce dnf repolist --enabled dosyasını kontrol edin.

EPEL'i sistemde sorun yaratmadan nasıl kaldırabilirim?

Öncelikle dnf repository-packages epel list installed ile envanter çıkarın, çünkü sadece epel-release paketini kaldırmak, EPEL'den kurulan diğer paketleri kaldırmaz. Bu paketler diskte kalır, güncelleme kaynaklarını kaybeder ve herhangi bir hata uyarısı vermeden güvenlik yamalarını almayı durdurur. Paket bazında karar verin, artık ihtiyacınız olmayanları kaldırın veya değiştirin, ardından sudo dnf remove epel-release komutunu çalıştırın. Eğer EPEL'den gelen bir paket hiçbir şeyin yerini almadıysa ve mutlaka gitmesi gerekiyorsa, sudo dnf repository-packages epel remove komutu tüm seti tek bir işlemde temizler; bu nedenle onaylamadan önce önerilen listeyi dikkatlice okuyun.