apt komutlarının dnf karşılıkları: Rocky ve Fedora

Kısa cevap

apt sisteminden dnf sistemine geçiş, büyük oranda bir terminoloji değişikliğidir. apt install nginx komutu dnf install nginx komutuna dönüşür. apt remove nginx komutu dnf remove nginx komutuna dönüşür. apt update komutunun doğrudan bir karşılığı yoktur; çünkü dnf, önbellekteki meta veriler eskidiğinde depo meta verilerini kendiliğinden günceller. Bu dönüşümün kolay kısmı tek bir ekranlık yer kaplar. Faydalı kısmı ise hiçbir karşılığı olmayan dört işlemden oluşur: depo ekleme, işlem geri alma, paket grubu kurma ve katılımsız güncellemeleri çalıştırma.

Aşağıdaki her komut, kendi sunucunuzda çalıştırmanız için yazılmıştır. Özellikle kaldırma işlemlerinde, y komutuna yanıt vermeden önce dnf tarafından yazdırılan işlem özetini mutlaka okuyun.

Hangi dağıtımlar dnf, hangileri apt kullanır

dnf; Fedora, Red Hat Enterprise Linux (RHEL) ve RHEL tabanlı yeniden yapılandırmalar olan Rocky Linux, AlmaLinux ve CentOS Stream üzerinde kullanılan paket yöneticisidir. apt; Debian ve Debian türevi olan tüm sistemlerde kullanılan paket yöneticisidir; bir VPS bağlamında bu neredeyse her zaman Ubuntu anlamına gelir. Üçüncü bir seçenek yoktur. Sağlayıcınızın imaj listesinde Rocky Linux veya AlmaLinux varsa dnf kullanırsınız. Ubuntu varsa apt kullanırsınız. Bu ayrımın bir tarafının, büyük ölçüde aynı sistem için neden dört farklı isim taşıdığı, seçim yapmadan önce bilinmesi gereken bir hikayedir ve Red Hat Linux'un nasıl Fedora, RHEL, CentOS, Rocky ve AlmaLinux haline geldiği her birinin kökenini açıklar.

Paket formatı, kullanılan araca göre değişiklik gösterir. dnf, .rpm dosyalarını kurar ve veritabanı rpm şeklindedir. apt, .deb dosyalarını kurar ve veritabanı dpkg şeklindedir. Birçok yazılım sağlayıcısının kurulum sayfalarında her aile için ayrı bir sekme bulunmasının ve bir projenin sürüm sayfasından indirilen .deb dosyasının Rocky Linux üzerinde işe yaramamasının nedeni budur.

Hangi aileye geçerseniz geçin, ilk oturum açma işlemindeki yapılacaklar aynıdır. Yeni bir VPS'te ilk on dakika her iki sistem için de geçerlidir. Yalnızca kurulum komutu değişir.

Her apt komutu ve dnf karşılığı

Kurulum, kaldırma, arama ve gösterme. Bu işlemler her iki tarafta da neredeyse aynı kelimeleri kullanır.

# apt
sudo apt install nginx
sudo apt remove nginx
apt search nginx
apt show nginx

# dnf
sudo dnf install nginx
sudo dnf remove nginx
dnf search nginx
dnf info nginx

apt show, dnf info ile aynıdır. Bu grupta ismi değiştirilen tek fiil budur ancak bir davranış farkı kullanıcıları yanıltabilir. dnf remove, başka hiçbir paketin ihtiyaç duymadığı bağımlılıkları da kaldırırken, apt remove bunları daha sonraki bir apt autoremove işlemi için sistemde bırakır. Bu nedenle, Rocky Linux üzerinde küçük bir yardımcı programı kaldırmak, beraberinde bir düzine kütüphanenin de kaldırılmasını önerebilir. Onay vermeden önce listeyi mutlaka okuyun.

Meta verileri yenileme, bekleyen güncellemeleri kontrol etme ve yükseltme.

# apt
sudo apt update
apt list --upgradable
sudo apt install --only-upgrade nginx
sudo apt upgrade

# dnf
sudo dnf makecache
dnf check-update
sudo dnf upgrade nginx
sudo dnf upgrade

apt update, apt tarafında zorunludur; çünkü apt diskteki mevcut meta verileri kullanır ve aylar öncesine ait bir sürümü sorunsuzca kurabilir. dnf ise her işlemden önce önbelleğinin yaşını kontrol eder ve meta verileri kendiliğinden günceller; bu yüzden sudo dnf makecache yalnızca bu indirme işlemini bir sonraki kurulumdan önce zorla başlatmak için kullanılır.

apt, sistem yükseltme işlemini ikiye böler, dnf ise bölmez. apt upgrade, yüklü hiçbir paketi kaldırmayı reddeder; bu nedenle bir güncelleme paketin kaldırılmasını gerektirdiğinde işlem durur. apt full-upgrade, kaldırma işlemine izin veren sürümdür. dnf'de böyle bir kısıtlama yoktur; bu da dnf upgrade komutunun apt upgrade ile değil, apt full-upgrade ile eşdeğer olduğu anlamına gelir. dnf update, aynı komut için kullanılan eski bir takma addır ve hala çalışmaktadır.

Script yazıyorsanız şu detay önemlidir: dnf check-update, güncellemeler beklediğinde 100, güncelleme olmadığında 0 çıkış kodu döndürür. apt list --upgradable ise her iki durumda da 0 döndürür, bu nedenle scriptlerin çıktısını ayrıştırmak gerekir.

Yüklü paketleri listeleme ve bir dosyanın hangi pakete ait olduğunu bulma.

# apt
dpkg -l
dpkg -S /usr/sbin/nginx
dpkg -L nginx
apt-file search /usr/sbin/nginx

# dnf
dnf list --installed
rpm -qf /usr/sbin/nginx
rpm -ql nginx
dnf provides /usr/sbin/nginx

Her bloğun son satırı, yukarıdakilerden farklı bir soruya yanıt verir. dpkg -S ve rpm -qf yalnızca yüklü paketler içinde arama yapar, yani "bu dosyayı buraya ne koydu" sorusunu yanıtlar. apt-file search ve dnf provides ise depoları tarar, yani "bu dosyayı elde etmek için ne kurmalıyım" sorusunu yanıtlar. apt-file, Ubuntu üzerinde ayrı bir pakettir ve ilk çalıştırmadan önce sudo apt-file update gerektirir. dnf provides için ek bir işleme gerek yoktur, ancak dnf depo dosya listelerini indirdiği için ilk çalıştırma yavaş olabilir.

Henüz kurmadığınız bir paketin içindeki dosyaları listelemek için dnf repoquery -l nginx kullanın. apt tarafında bu işlem apt-file list nginx ile yapılır.

Otomatik kaldırma, önbelleği temizleme ve sürüm sabitleme.

# apt
sudo apt autoremove
sudo apt clean
sudo apt-mark hold nginx
apt-mark showhold
sudo apt-mark unhold nginx

# dnf
sudo dnf autoremove
sudo dnf clean all
sudo dnf versionlock add nginx
dnf versionlock list
sudo dnf versionlock delete nginx

versionlock, Rocky Linux veya AlmaLinux üzerinde varsayılan olarak yüklü gelmez, bu nedenle yeni bir sistemde bu satırların ilki No such command: versionlock hatası verir. Önce sudo dnf install python3-dnf-plugin-versionlock ile kurun. apt, apt-mark hold için ek bir şeye ihtiyaç duymaz; çünkü sürüm sabitleme (hold), bir eklentiden ziyade dpkg durumudur.

Eşlemenin bozulduğu nokta: depo ekleme

Bu kısım, Ubuntu yöneticilerini var olmayan bir komutu aramaya iten bölümdür. dnf üzerinde add-apt-repository bulunmaz ve kişisel paket arşivleri (PPA) yoktur. PPA, Launchpad tarafından yürütülen bir servistir ve Launchpad bir Ubuntu altyapısıdır. RPM dünyasında buna karşılık gelen bir barındırma hizmeti yoktur.

Bunun yerine dnf, /etc/yum.repos.d/ dizininde her depo için .repo uzantılı düz bir metin dosyası kullanır.

[docker-ce-stable]
name=Docker CE Stable
baseurl=https://download.docker.com/linux/centos/$releasever/$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg

$releasever ve $basearch, dnf değişkenleridir. dnf, çalışma zamanında ana sürüm numaranızı ve CPU mimarinizi otomatik olarak doldurur; böylece aynı dosya hem sürüm 9 hem de sürüm 10 üzerinde, ayrıca hem x86_64 hem de aarch64 mimarilerinde çalışır.

Çoğu tedarikçi bu dosyayı yayınlar ve indirmenizi ister. Docker'ın RHEL ve türevleri için kendi talimatları iki komuttan oluşur:

sudo dnf -y install dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

İlk satır gereklidir çünkü config-manager, dnf'in kendisinin bir parçası değil, bir eklentidir. Bu satırı atlarsanız ikinci satır No such command: config-manager hatasıyla başarısız olur. Aynı .repo dosyasını curl ile /etc/yum.repos.d/ dizinine elle indirmenize hiçbir engel yoktur; sonuç tamamen aynı olacaktır. VPS üzerinde Docker kurulumu, aynı işlemin Debian tarafını ele alır; orada eşdeğer adım, bir kaynak listesi ve bir imzalama anahtarını iki farklı dizine yazar.

Düzen farkı, bir depo düzgün çalışmadığında nereye bakacağınızı belirler. apt, tanımları /etc/apt/sources.list ve /etc/apt/sources.list.d/ içinde tutar, imzalama anahtarları ise ayrı olarak /etc/apt/keyrings/ altında saklanır. dnf ise her şeyi /etc/yum.repos.d/ içinde tutar ve anahtar, .repo dosyası içindeki bir URL'dir; dolayısıyla okunacak tek bir dosya ve silinecek tek bir dosya vardır. Daha yeni apt sürümleri, depo başına bir .sources dosyası içeren deb822 formatıyla benzer bir yapıya geçmiştir. Eğer Ubuntu üzerinde deb822 yinelenen kaynak hatası ile karşılaştıysanız, bu sorunun apt tarafındaki karşılığıyla zaten tanışmışsınız demektir.

EPEL, çoğu rehberin varsaydığı arşivdir

Extra Packages for Enterprise Linux (EPEL), RHEL ve türevleri için Fedora paketleri üreten bir Fedora projesidir. Bu dünya için evrensel bir PPA'ya en yakın şeydir ve çok sayıda rehber, bunun halihazırda etkinleştirilmiş olduğunu varsayar. Eğer projenin kendi web sitesinde görebildiğiniz bir paket için dnf install, No match for argument yanıtını veriyorsa, kontrol edilmesi gereken ilk şey EPEL'dir.

Rocky Linux ve AlmaLinux üzerinde:

sudo dnf config-manager --set-enabled crb
sudo dnf install epel-release
sudo dnf makecache

CRB (CodeReady Builder), dağıtımla birlikte gelen ancak varsayılan olarak etkinleştirilmeyen bir kütüphane deposudur. Çoğu EPEL paketi, bu depodaki bir öğeye bağımlıdır; bu nedenle CRB olmadan EPEL'i etkinleştirmek o an için bir hata vermez. Hata daha sonra, kurulum aşamasında, daha önce hiç duymadığınız bir pakete dair çözülemeyen bağımlılıklar nedeniyle ortaya çıkar. Önce CRB'yi etkinleştirin, bu tür hatalar ortadan kalkacaktır.

RHEL üzerinde CRB, config-manager yerine aboneliğiniz aracılığıyla gelir; bu nedenle ilgili adım için Red Hat'in kendi EPEL yönergelerini izleyin. Fedora'da bunlara gerek yoktur, çünkü ana deposu zaten EPEL'in geriye dönük taşıdığı paketleri içerir. EPEL politikası, RHEL'in sunduğu hiçbir paketin yerine geçmemektir; bu nedenle depoyu eklemek, sunucunuzda halihazırda yüklü olan hiçbir şeyi değiştirmez.

dnf history undo, apt'nin yapamadığı işlem

dnf her işlemi kaydeder ve bu işlemlerin tersini oluşturabilir.

sudo dnf history
sudo dnf history info 42
sudo dnf history undo 42

dnf history, her işlemi başlatan komut satırı ile birlikte numaralandırılmış bir işlem listesi yazdırır. undo, işlemin tersini oluşturur: o işlemle yüklenen paketler kaldırılır ve yükseltilen paketler sahip olduğunuz önceki sürüme geri döndürülür. Bu, apt kullanıcılarının geçiş yaptıktan sonra en çok özlediği özelliktir.

Bu özelliğin gerçek sınırları vardır ve bunlara güvenmeden önce bilinmeleri gerekir. undo, yalnızca etkin bir depoda hâlâ mevcut olan bir paket sürümünü yeniden yükleyebilir; bu nedenle eski yapı (build) yansıtıcıdan (mirror) kaldırıldığında, geri alma işlemi bulunamadı hatasıyla başarısız olur. Geri alma işlemi yalnızca paket veritabanında durur. Yükseltme sırasında üzerine yazılan bir yapılandırma dosyası öyle kalır ve bir servisin ilk başlatmada geçiş yaptığı veritabanı şeması da öyle kalır. dnf dosyaları geri yükler. Verilerinizi geri getirmez.

apt'nin buna eşdeğer bir özelliği yoktur. /var/log/apt/history.log, komut satırı da dahil olmak üzere tam olarak ne olduğunu kaydeder ancak bir günlüğü okumak, işlemi geri almak değildir. apt tarafında kurtarma manueldir: arşivin hâlâ hangi sürümleri tuttuğunu görmek için apt list -a nginx komutunu çalıştırın, ardından bir sürümü sabitlemek için sudo apt install nginx=<exact version string> komutunu kullanın ve bir sonraki yükseltmenin düzeltmenizi geri almaması için sudo apt-mark hold nginx ayarını ekleyin.

Paket gruplarının apt karşılığı yoktur

dnf, isimlendirilmiş bir paket kümesini tek bir komutla kurabilir.

dnf group list
dnf group info "Development Tools"
sudo dnf group install "Development Tools"

Eski kılavuzlar dnf groupinstall "Development Tools" yazmaktadır. Bu takma ad dnf 4 üzerinde çalışır ancak dnf 5 sürümünde kaldırılmıştır; bu nedenle iki kelimelik dnf group install yazımı her yerde çalışan tek yöntemdir. Bunu kullanın ve başka bir şey düşünmeyin.

apt sisteminde gruplar yoktur. Debian tarafındaki en yakın kavram, içeriği yalnızca bağımlılık listesinden oluşan boş bir paket olan metapackage yapısıdır; örneğin build-essential. Pratik fark şudur: bir metapackage kaldırıldığında, siz apt autoremove komutunu çalıştırana kadar bağımlılıkları yüklü kalır; oysa dnf group remove komutu, grubun paketlerini aynı işlemle birlikte kaldırır.

unattended-upgrades ve dnf-automatic

Her iki aile de kimse oturum açmamışken güncellemeleri yüklemenin bir yolunu sunar. Bu araçlar, amaçları dışında hiçbir ortak noktaya sahip değildir.

Ubuntu ve Debian üzerinde paket unattended-upgrades olarak adlandırılır ve /etc/apt/apt.conf.d/50unattended-upgrades dosyasında yapılandırılır; burada güncellemelerin çekilmesine izin verilen kaynakları listelersiniz. Ubuntu üzerinde unattended-upgrades kurulumu rehberi, bu yapılandırma dosyasını ve beraberinde gelen yeniden başlatma sorusunu ele alır.

Rocky Linux, AlmaLinux ve Fedora üzerinde paket dnf-automatic olarak adlandırılır ve davranış, etkinleştirdiğiniz systemd zamanlayıcısı tarafından belirlenir.

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic-install.timer
systemctl list-timers 'dnf-automatic*'

dnf-automatic-install.timer güncellemeleri indirir ve uygular. dnf-automatic-download.timer güncellemeleri indirir ve durur; yükleme işlemini size bırakır. dnf-automatic-notifyonly.timer ise yalnızca raporlama yapar. Bu birimlerin her biri, /etc/dnf/automatic.conf içindeki apply_updates ayarını geçersiz kılar; bu nedenle seçtiğiniz zamanlayıcı, yapılandırma dosyasındaki ifadeden daha önemlidir. Bir güncellemenin yüklenmesi, eski kodu çalıştırmaya devam eden süreçleri yeniden başlatmaz; bu nedenle sunucunun yamalandığını varsaymadan önce hangi güncellemelerin yeniden başlatma gerektirdiğini ve hangilerinin yalnızca servis yeniden başlatmasıyla tamamlandığını kontrol etmek faydalıdır.

Yalnızca güvenlik düzeltmeleriyle sınırlamak için /etc/dnf/automatic.conf dosyasında upgrade_type = security ayarını yapın. Bu filtre, depolarınızın güvenlik hatalarını (errata) yayınlamasına bağlıdır; bu yüzden önce dnf updateinfo list security ile kontrol edin. Bekleyen güncellemeleri olan bir sunucuda boş bir sonuç almanız, meta verilerin mevcut olmadığı anlamına gelir ve bu durumda security hiçbir şey yüklemeyecektir.

Fedora üzerinde dnf 5, birimi yeniden adlandırmıştır. Birim adı dnf5-automatic.timer şeklindedir ve aynı /etc/dnf/automatic.conf dosyasını okur.

yum hala gerçek bir komut mu?

Evet, ancak tek başına bir işlev görmez. Rocky Linux, AlmaLinux ve CentOS Stream üzerinde /usr/bin/yum, dnf'i işaret eden sembolik bir bağlantıdır. Kendi sisteminizi kontrol edin:

ls -l /usr/bin/yum
dnf --version

Eski yum sözdizimi, büyük oranda doğrudan dnf'e iletildiği için eğitimlerde görünmeye devam etmektedir. yum install, yum remove ve yum update komutlarının tümü çalışır. Bir alışkanlığı terk etmekte fayda vardır: yum-config-manager, dnf 4 sistemlerinde kendi ikili dosyası olarak varlığını sürdürse de, dnf config-manager güncel belgelerde kullanılan yazım biçimidir ve sistem dnf 5 sürümüne geçtiğinde çalışmaya devam edecek olan tek komuttur.

dnf 4 ve dnf 5: komut kopyalamadan önce kontrol edin

dnf 5, yeniden yazılmış bir sürümdür ve birçok komutun yazımını değiştirmiştir. Fedora 41 ve sonraki sürümler bunu dnf olarak sunar. Kurumsal yeniden yapılandırmalar (rebuilds) geçiş konusunda daha yavaştır, bu nedenle dağıtım adına bakarak tahminde bulunmayın. Kendi sunucunuzda dnf --version komutunu çalıştırın ve ilk satırı okuyun; aşağıdaki sözdizimlerinden hangisine ihtiyacınız olduğunu bu numara belirler.

Bunun en net örneği, her biri için farklı bir depo komutu yayınlayan Docker'dır. RHEL ve türevlerinde, dnf 4 ile:

sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

Fedora'da, dnf 5 ile:

sudo dnf config-manager addrepo --from-repofile https://download.docker.com/linux/fedora/docker-ce.repo

Aynı üretici, aynı iş, farklı kelimeler. dnf 5, config-manager aracını alt komut tabanlı bir araca dönüştürdü; bu nedenle eski --add-repo bayrağı kabul edilmez ve depo eklemek yerine kullanım hatası alırsınız. Karşılaşacağınız diğer bir durum ise bir depoyu etkinleştirmektir: dnf 4 üzerindeki dnf config-manager --set-enabled crb, dnf 5 üzerinde dnf config-manager setopt crb.enabled=1 haline gelir.

Gerçekten önemli olan seçim

Bir sunucu dağıtımını yalnızca paket yöneticisine göre seçmek yanlış bir yaklaşımdır. dnf ve apt aynı işi yapar; komut setine alışmak ise bir öğleden sonranızı alır. Yılınızı etkileyecek olan şey, deponun arkasındaki sürüm modelidir. Fedora hızlı ilerler ve belirli bir sürüm, yayınlandıktan yaklaşık on üç ay sonra güncelleme almayı durdurur; bu durum bir iş istasyonu için kabul edilebilir olsa da, yeniden kurmak istemediğiniz bir sunucu için zahmetlidir. Rocky Linux ve AlmaLinux, RHEL'i takip eder; bu sayede on yıllık bir destek süresine ve kasıtlı olarak sabit kalan paket sürümlerine sahip olursunuz. Ubuntu her iki modeli de sunar ve sunucuda Ubuntu LTS ile ara sürümler arasındaki fark, apt dünyası içinde verilen aynı karardır.

Ağustos 2026 itibarıyla, bunların tümü standart VPS imajlarıdır. İstediğiniz destek süresini seçin ve ardından yukarıdaki on komutu öğrenin.

FAQ

apt update komutunun dnf karşılığı nedir?

Çalıştırmanız gereken özel bir komut yoktur. dnf, her işlemden önce önbelleğe alınmış meta verilerinin ne kadar eski olduğunu kontrol eder ve süresi dolduğunda güncel bir kopyasını indirir; bu nedenle bir aydır dokunmadığınız bir sunucuda dnf install komutu hala güncel paketleri görür. sudo dnf makecache komutu mevcuttur ve indirme işlemini zorlar, ancak asıl kullanım amacı bu gecikmeyi bir sonraki kurulumunuza değil, seçtiğiniz bir zamana taşımaktır. "Beni ne bekliyor" sorusunun cevabı, apt list --upgradable ile eşleşen ve güncellemeler mevcut olduğunda 100 durum koduyla çıkan dnf check-update komutudur.

Rocky Linux veya Fedora üzerinde PPA karşılığı var mı?

Hayır. Kişisel paket arşivleri (PPA) bir Launchpad servisidir ve Launchpad bir Ubuntu altyapısıdır; bu nedenle add-apt-repository karşılığında çevrilecek bir şey yoktur. RPM dünyasındaki karşılığı, /etc/yum.repos.d/ dizini içinde bir isim, bir baseurl ve bir gpgkey barındıran bir .repo dosyasıdır. Satıcılar bu dosyayı sizin için yayınlar; dnf 4 üzerinde sudo dnf config-manager --add-repo <url> veya dnf 5 üzerinde sudo dnf config-manager addrepo --from-repofile <url> komutu bu dosyayı indirip yerine yerleştirir. Genel ek yazılımlar için cevap genellikle EPEL'dir; bunu sudo dnf config-manager --set-enabled crb ve ardından sudo dnf install epel-release ile etkinleştirebilirsiniz.

Sunucumu bozan bir dnf upgrade işlemini geri alabilir miyim?

Evet, belirli sınırlar dahilinde. İşlem numarasını bulmak için sudo dnf history, tam olarak nelerin değiştiğini görmek için sudo dnf history info <id> ve ardından geri almak için sudo dnf history undo <id> komutunu çalıştırın. Eski paket sürümü etkinleştirilmiş herhangi bir depoda artık mevcut değilse, dnf yeniden kuracak bir kaynak bulamayacağı için geri alma işlemi başarısız olur. Bu işlem yalnızca paket değişikliklerini geri alır. Yükseltme tarafından üzerine yazılan bir yapılandırma dosyası veya servis ilk başlatıldığında göç ettirilen bir veritabanı olduğu gibi kalır. apt tarafında buna karşılık gelen bir komut yoktur, yalnızca /var/log/apt/history.log içindeki kayıtlar mevcuttur.

yum, Rocky Linux ve AlmaLinux üzerinde hala çalışıyor mu?

Çalışır çünkü /usr/bin/yum, dnf'e giden sembolik bir bağlantıdır. Kendi sisteminizde ls -l /usr/bin/yum ile bunu doğrulayabilirsiniz. yum install httpd yazmak dnf'i çalıştırır, bu nedenle eski eğitimlerin çoğu hala işlevseldir. yum ismi yalnızca uyumluluk içindir; yeni betikleri ve belgeleri dnf ile yazın ve eski yum-config-manager ikili dosyası yerine dnf config-manager komutunu tercih edin.

dnf remove neden bu kadar çok paketi silmek istiyor?

Çünkü dnf, aynı işlemin bir parçası olarak başka hiçbir paketin ihtiyaç duymadığı bağımlılıkları kaldırır; oysa apt remove, siz ayrı olarak apt autoremove komutunu çalıştırana kadar bunları yüklü bırakır. Bu nedenle Ubuntu üzerinde küçük görünen bir kaldırma işlemi, Rocky Linux üzerinde uzun bir liste yazdırabilir. Liste genellikle doğrudur ancak onaylamadan önce okuyun. Listede tutmak istediğiniz bir paket varsa, dnf'in onu kendi başına gerekli olarak kaydetmesi için önce onu açıkça kurun.