Rocky Linux ve AlmaLinux'ta EPEL ve CRB Depoları

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. Herhangi bir bozulma 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çinde 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 sınıflandırır 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ımları içerir: bu depoların neleri taahhüt ettiği, neleri taahhüt 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 belgelerini takip eder. 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: kernel, 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 (backport) uygulanır. BaseOS içinde yıllar öncesinden kalmış 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ı (runtimes), 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 neredeyse tüm modülerliği kaldırdı; bu yüzden Rocky 9 ve Alma 9 üzerinde genellikle bir şeyin tek bir sürümünü alırsınız ve önce etkinleştirmeniz 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 neden rastgele bir URL'ye güvenmenize gerek olmadığının nedenidir.

CRB, sürüm 8'de PowerTools olarak adlandırılan CodeReady Builder deposudur. Dağıtımın derleme tarafını barındırır: geliştirme başlıkları (headers), statik kütüphaneler ve paketlerin derleme zamanında ihtiyaç duyduğu test ve dokümantasyon araçları. Bu depo aynalarda (mirror) zaten 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 dünyasından gelen okuyucular için: main, çalışma zamanı paketlerini ve -dev başlıklarını tek bir arşivde birleştirir, 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 paketlerin güncel kurumsal sürümler için yeniden derlenmiş halidir. EPEL Özel İlgi Grubu (Special Interest Group) tarafından yönetilir; bu grup büyük ölçüde Fedora topluluğundaki gönüllülerden oluşur. Red Hat, derleme ve yansıma (mirror) altyapısını barındırır ve bazı Red Hat mühendisleri paketlerin bakımına katkıda bulunur. İlişki burada sona erer. EPEL bir Red Hat ürünü değildir. EPEL paketleri için RHEL veya yeniden derlenmiş sürümler üzerinde herhangi bir 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 yalnızca EPEL ile ilgili bir taahhüttür. Daha sonra eklediğiniz diğer hiçbir şey için sizi 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ü 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 bir duyuru olmaksızın güncelleme almayı durdurabilir. Ayrıca yeni bir sürüm, halihazırda çalışan bir serviste hemen devreye girmez; bu yüzden işlem tamamlandığında hangi süreçlerin hala eski ikili dosyayı kullandığını size needs-restarting bildirir.

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 ait bir nokta 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 ve 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 öğelerini listelemelidir. 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; eski CentOS 8 belgeleri bunu büyük harflerle PowerTools şeklinde yazar ancak bu eşleşmeyecektir. 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. O dosyadaki gpgcheck=1 değerini doğrulayın ve sizi imza hatasını --nogpgcheck ile aşmaya yönlendiren hiçbir kılavuzu dikkate almayın. Başarısız bir imza denetimi, paketin iddia ettiği şey olmadığı veya sistem saatinizin yanlış olduğu anlamına gelir.

Rocky üzerinde epel-release, /usr/bin/crb konumuna küçük bir yardımcı araç da kurar; bu sayede sudo crb enable ve crb status eklenti olmadan 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ğu ancak hiçbir sonuç döndürmediği anlamına gelir; bu genellikle bir yapılandırma sorunundan ziyade bir yansıma (mirror) veya meta veri sorunudur, bu yüzden 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, dnf'in yerleşik bir alt komutu değil, bir eklentisidir. Tam sunucu kurulumlarında 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özdizimi olduğundan, tırnak kullanılmayan bir sürüm dnf hatası yerine sözdizimi hatası verir.

Eğer ihtiyacınız olan depo devre dışı olduğu için eklentiyi kuramıyorsanız, dosyayı manuel olarak düzenleyin. İlgili bölümü içeren dosyayı bulun, açın ve [crb] altındaki enabled=1 değerini şu şekilde 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 yapmak herhangi bir kayba yol açmaz. dnf repolist --enabled komutu sonucu doğrular.

Bazı EPEL paketleri CRB etkinleştirilmeden kurulamaz

İkinci yaygın tuzak, hiçbir zaman CRB'den 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üyor ancak normal kurulum hala başarısız oluyorsa, CRB kapalıdır. Bu hata türü o kadar yaygındır ki AlmaLinux, bunun yaşanmasını engellemek için 10. sürümde CRB'yi varsayılan olarak etkinleştirmiştir. --enablerepo=crb de tek seferlik bir kurulumda bayrak olarak 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ç haftanın ardından, 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 bir @ ile gösterir; bu nedenle @epel, paketin EPEL'den yüklendiği, @System ise dnf'in paketin kaynağını bilmediği anlamına gelir; bu durum genellikle birinin indirilen bir dosya üzerinde rpm -i çalıştırmasıyla oluşur. repoquery satırı, depo başına bir sayı 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, bir deponun size tam olarak ne verdiğini listeler ve bir depoyu kaldırmaya karar vermeden önce ihtiyacınız olan envanter budur.

Buradaki apt alışkanlığı apt-cache policy <package> komutudur ve dnf ve apt komut karşılıkları belgesini ilk ay boyunca ikinci bir sekmede açık tutmak faydalıdır; çünkü kavramlar, bayraklar (flags) farklı olsa bile birbirleriyle net bir şekilde eşleşir.

Üçüncü taraf bir deponun temel bir paketin yerini almasını 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ü sunabilir. dnf'in varsayılan kuralı basit olduğu için dnf bunu yükleyecektir: nereden gelirse gelsin, en yüksek sürüm kazanır.

İki kontrol 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 adını birden fazla depo taşıdığında hangisinin 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. 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=, bir depodan belirli paketleri engeller; bu da deponun ne sunabileceğ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ı adı sağladığında gizlenebilir ve o deponun bölümündeki module_hotfixes=1, dnf'e bu filtrelemeyi durdurmasını söyler. Eğer bir paket dnf repoquery tarafından görülebiliyor ancak bir 8 sunucusuna yüklenemiyorsa, 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 yükleyin 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ırmanın sunucuyu neden yükseltilemez hale getirdiği

Rocky, Alma, CentOS Stream, Oracle Linux ve RHEL, paketlerinin birbirine kurulabileceği kadar yakın, ancak sonuçta kimsenin destekleyemeyeceği bir sistem oluşturacak kadar da uzaktır. Bu kadar yakın olmalarının ve özellikle Stream'in neden RHEL'in yanında değil de önünde yer aldığının nedeni, Red Hat Linux'un Fedora ve RHEL olarak nasıl ayrıldığı ve CentOS'un neye dönüştüğünün hikayesidir.

Bunun mekanizması 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 kalır ve dnf upgrade ona dokunmaz. 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, sudo dnf distro-sync komutunun ise uzun bir paket listesini eski sürüme düşürmeyi (downgrade) önermesidir. distro-sync onarım aracıdır: yüklü her paketi, etkin depolarda sunulanlarla eşleşmeye zorlar; buna eski sürüme düşürme işlemleri de dahildir. Önce yabancı depoyu devre dışı bırakın, ardından komutu çalıştırın ve kabul etmeden önce önerilen listeyi okuyun. Eski RPM paketi artık yansıda (mirror) 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 türüdür. ELevate, bir CentOS 7 sunucusunu ileri taşımak veya yeniden derlenmiş dağıtımlar arasında geçiş yapmak için Leapp üzerine inşa edilmiş AlmaLinux taşıma aracıdır. Aceleye getirilmiş bir taşıma işlemi, /etc/yum.repos.d/ dizininde EL7 depo dosyalarının ve hala yüklü olan EL7 paketlerinin kalmasına neden olur. Bunları rpm -qa | grep el7 ile bulun. Bunların her biri, etkin 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, bu yüzden birinden vazgeçmeniz gerekir. Bir kez karar verin, dışlamayı not edin ve bilinen iyi bir sırayı izleyin: Rocky Linux üzerinde Docker kurulumu kılavuzu, hangi dağıtım paketlerinin önce kaldırılması gerektiğini açıklar.

apt'den dnf'ye depo (repository) geçişi

• /etc/apt/sources.list.d/*.sources, /etc/yum.repos.d/*.repo haline gelir; burada tek bir dosya, her biri kendi kimliğine sahip birden fazla [sections] barındırabilir.
• add-apt-repository universe, dnf install epel-release haline gelir; aradaki fark, universe'un Ubuntu'nun kendi arşivinde yer alması, EPEL'in ise ayrı bir proje olmasıdır.
• apt update'ın 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>, dnf info <pkg> haline gelir; ayrıca sunulan tüm sürümleri görmek için dnf list --showduplicates <pkg> kullanılır.
• apt-mark hold, python3-dnf-plugin-versionlock içinden dnf versionlock add haline gelir.
• /etc/apt/preferences.d/ içindeki sabitleme (pinning), depo bölümünde priority= haline gelir ve numaralar ters yönde işler.
• dpkg -S /path/to/file, rpm -qf /path/to/file haline gelir.

Otomatik güncellemeler, söz dizimi olarak değil fikir olarak aktarılır çünkü burada unattended-upgrades yoktur. Zamanlayıcı, yapılandırma dosyası ve yeniden başlatma gerekliliği gibi konular Rocky ve Alma üzerinde dnf-automatic bölümünde 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 dosyaya not edin. Sunucu üç yıllık olduğunda ve yönetimi başkasına devrettiğinizde, 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 ve ancak o zaman 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; çünkü 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 düzenin her ikisinde de aynı olduğunu ve epel-release aracının her iki tarafta da aynı ş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 oluşturma yerine ABI (uygulama ikili arayüzü) uyumluluğunu hedeflemesi nedeniyle yeniden oluşturma felsefesindeki farkları ele almaktadır.

FAQ

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

sudo dnf install -y dnf-plugins-core komutunu, ardından sudo dnf config-manager --set-enabled crb ve sudo dnf install -y epel-release komutlarını çalıştırın. dnf repolist --enabled ile onaylayın; bu komut baseos, appstream, extras, crb ve epel öğelerini listelemelidir. 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'de 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 bir paketin yerini asla almaması politikası üzerine kuruludur; bu nedenle etkinleştirmek, BaseOS veya AppStream'in sağladığı paketleri değiştirmez. Buradaki çekince destektir: EPEL, hizmet seviyesi anlaşması 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üşteriye dönük 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 ayarını manuel olarak yapın.

CRB ve PowerTools arasındaki fark nedir?

Bunlar aynı deponun iki farklı ismidir. Sürüm 8, powertools kimliğiyle PowerTools olarak adlandırırken, sürüm 9 ve sonrası crb kimliğiyle CRB olarak adlandırır; Red Hat'in kendi ürünü ise bu içeriği CodeReady Linux Builder olarak adlandırır. Bu depo geliştirme başlıklarını, statik kütüphaneleri ve derleme zamanı araçlarını barındırır; 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?

Önce dnf repository-packages epel list installed ile envanter çıkarın, çünkü sadece epel-release paketini kaldırmak EPEL'den kurulan hiçbir şeyi 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, ancak ondan sonra sudo dnf remove epel-release komutunu çalıştırın. EPEL'den gelen bir paket hiçbir şeyin yerini almadıysa ve mutlaka gitmesi gerekiyorsa, sudo dnf repository-packages epel remove komutu seti tek bir işlemde temizler; bu nedenle onaylamadan önce önerilen listeyi dikkatlice okuyun.