Rocky आणि Fedora साठी apt कमांडचे dnf पर्याय

संक्षिप्त उत्तर

apt वरून dnf कडे जाणे हे मुख्यतः संज्ञांमधील बदल आहे. apt install nginx चे रूपांतर dnf install nginx मध्ये होते. apt remove nginx चे रूपांतर dnf remove nginx मध्ये होते. apt update ला थेट समतुल्य नाही, कारण cache केलेली repository metadata जुनी झाल्यावर dnf ती स्वतः refresh करते. भाषांतराचा सोपा भाग एका स्क्रीनमध्ये मावतो. उपयुक्त भाग म्हणजे एकमेकांशी थेट जुळत नसलेल्या चार प्रक्रिया: repository जोडणे, transaction पूर्ववत करणे, package group install करणे आणि unattended updates चालवणे.

खालील प्रत्येक command तुमच्या स्वतःच्या server वर चालवण्यासाठी दिला आहे. y ला उत्तर देण्यापूर्वी dnf दाखवणारा transaction summary वाचा, विशेषतः removals च्या बाबतीत.

dnf कोणते distros वापरतात आणि apt कोणते वापरतात

Fedora, Red Hat Enterprise Linux (RHEL) आणि RHEL च्या पुनर्बांधणी केलेल्या आवृत्त्यांवर — Rocky Linux, AlmaLinux आणि CentOS Stream — dnf हे package manager आहे. Debian आणि Debian वर आधारित सर्व distros वर apt हे package manager आहे. VPS च्या संदर्भात याचा अर्थ जवळजवळ नेहमी Ubuntu असा होतो. तिसरे उत्तर नाही. तुमच्या provider च्या image list मध्ये Rocky Linux किंवा AlmaLinux असल्यास तुम्हाला dnf मिळेल. त्यात Ubuntu असल्यास तुम्हाला apt मिळेल. मोठ्या प्रमाणावर समान असलेल्या system साठी या विभाजनाच्या एका बाजूला चार नावे का आहेत, ही बाब distro निवडण्यापूर्वी समजून घेणे उपयुक्त आहे. Red Hat Linux चे Fedora, RHEL, CentOS, Rocky आणि AlmaLinux मध्ये रूपांतर कसे झाले यामध्ये प्रत्येक distro ची उत्पत्ती स्पष्ट केली आहे.

Package format हा tool नुसार बदलतो. dnf .rpm files install करते आणि तिचा database rpm असतो. apt .deb files install करते आणि तिचा database dpkg असतो. त्यामुळे अनेक vendor install pages वर प्रत्येक family साठी स्वतंत्र tab असतो. तसेच project च्या release page वरून download केलेले .deb Rocky Linux वर निरुपयोगी असते.

तुम्ही कोणतीही family निवडली तरी पहिल्या login वेळी करायचे काम समान असते. नवीन VPS वरील पहिले दहा मिनिटे दोन्हींसाठी लागू होतात. फक्त install command बदलते.

प्रत्येक apt कमांड आणि त्याचा dnf समतुल्य

स्थापित करणे, काढून टाकणे, शोधणे आणि माहिती दाखवणे. दोन्ही बाजूंवर यासाठी जवळपास समान शब्द वापरले जातात.

# 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. या गटातील नाव बदललेली ही एकमेव क्रिया आहे; मात्र एका वर्तनात फरक आहे आणि त्यामुळे अनेकांना अडचण येते. dnf remove अशा dependency देखील काढून टाकते ज्या इतर कोणत्याही पॅकेजला आवश्यक नसतात, तर apt remove त्या पुढील apt autoremove साठी स्थापित ठेवते. त्यामुळे Rocky Linux वर एखादे छोटे utility काढताना त्यासोबत डझनभर library काढण्याचा प्रस्ताव येऊ शकतो. पुष्टी करण्यापूर्वी यादी वाचा.

Metadata refresh करणे, कोणती अद्यतने प्रतीक्षेत आहेत ते तपासणे आणि upgrade करणे.

# 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 च्या बाजूला apt update आवश्यक आहे, कारण apt डिस्कवरील उपलब्ध metadata वापरते आणि काही महिन्यांपूर्वी archive मधून काढलेली version देखील स्थापित करू शकते. प्रत्येक transaction पूर्वी dnf आपल्या cache चे वय तपासते आणि स्वतःहून नवीन metadata डाउनलोड करते. त्यामुळे sudo dnf makecache केवळ हे डाउनलोड आत्ताच घडवून आणण्यासाठी वापरले जाते; पुढील install दरम्यान ते होण्याची प्रतीक्षा करावी लागत नाही.

apt संपूर्ण system upgrade दोन भागांत विभागते; dnf तसे करत नाही. apt upgrade कोणतेही स्थापित package काढण्यास नकार देते. त्यामुळे एखादे update एखादे package काढणे आवश्यक करत असल्यास ते मध्येच थांबते. apt full-upgrade ही काढण्यास अनुमती असलेली version आहे. dnf वर अशी मर्यादा नाही. त्यामुळे dnf upgrade हे apt full-upgrade चे समतुल्य आहे, apt upgrade चे नाही. dnf update हे त्याच command चे जुने alias आहे आणि अजूनही कार्य करते.

हे script मध्ये वापरताना एक तपशील महत्त्वाचा आहे: अद्यतने प्रतीक्षेत असताना dnf check-update status 100 सह बाहेर पडते आणि कोणतीही अद्यतने नसताना 0 सह बाहेर पडते. apt list --upgradable दोन्ही परिस्थितींमध्ये 0 सह बाहेर पडते. त्यामुळे script ला त्याचे output parse करावे लागते.

काय स्थापित आहे ते यादीत दाखवणे आणि एखाद्या file च्या मालकीचे package शोधणे.

# 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

प्रत्येक block ची शेवटची ओळ त्यापूर्वीच्या ओळींपेक्षा वेगळ्या प्रश्नाचे उत्तर देते. dpkg -S आणि rpm -qf केवळ आधीपासून स्थापित package शोधतात. त्यामुळे ते “ही file येथे कोणत्या package ने ठेवली” या प्रश्नाचे उत्तर देतात. apt-file search आणि dnf provides repositories मध्ये शोध घेतात. त्यामुळे ते “ही file मिळवण्यासाठी कोणते package install करावे” या प्रश्नाचे उत्तर देतात. apt-file हे Ubuntu वर स्वतंत्र package आहे आणि पहिल्यांदा चालवण्यापूर्वी sudo apt-file update आवश्यक आहे. dnf provides साठी अतिरिक्त काहीही आवश्यक नाही. मात्र पहिल्यांदा चालवताना ते संथ असू शकते, कारण उत्तर देण्यासाठी dnf repository मधील file lists डाउनलोड करते.

अद्याप स्थापित न केलेल्या package मधील files ची यादी पाहण्यासाठी dnf repoquery -l nginx वापरा. apt च्या बाजूला त्यासाठी apt-file list nginx वापरले जाते.

Autoremove करणे, cache साफ करणे आणि एखादी version hold करणे.

# 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

Rocky Linux किंवा AlmaLinux वर versionlock default ने स्थापित केलेले नसते. त्यामुळे नवीन system वर या ओळींपैकी पहिली ओळ No such command: versionlock सह अपयशी ठरते. ते प्रथम sudo dnf install python3-dnf-plugin-versionlock वापरून स्थापित करा. apt-mark hold साठी apt ला अतिरिक्त काहीही आवश्यक नाही, कारण hold ही plugin ची स्थिती नसून dpkg state आहे.

मॅपिंग कुठे मोडते: repository जोडताना

हा तो भाग आहे ज्यामुळे Ubuntu admins अस्तित्वात नसलेल्या command च्या शोधात वेळ घालवतात. dnf मध्ये add-apt-repository नाही आणि personal package archives (PPAs) देखील नाहीत. PPA ही Launchpad द्वारे चालवली जाणारी service आहे आणि Launchpad ही Ubuntu infrastructure आहे. RPM विश्वात अशी कोणतीही service host केलेली नाही.

dnf मध्ये त्याऐवजी प्रत्येक repository साठी /etc/yum.repos.d/ मध्ये एक plain text file असते. तिचा शेवट .repo ने होतो.

[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 आणि $basearch हे dnf variables आहेत. dnf runtime वर तुमचा major release number आणि CPU architecture भरतो. त्यामुळे तीच file version 9 आणि version 10 तसेच x86_64 आणि aarch64 वर काम करते.

बहुतेक vendors ही file publish करतात आणि ती fetch करण्यास सांगतात. RHEL आणि त्याच्या rebuilds साठी Docker च्या स्वतःच्या instructions मध्ये दोन commands आहेत:

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

पहिली line आवश्यक आहे कारण config-manager हा plugin आहे आणि dnf चा अंगभूत भाग नाही. ती वगळल्यास दुसरी line No such command: config-manager सह fail होते. तीच .repo file curl वापरून स्वतः download करून /etc/yum.repos.d/ मध्ये ठेवण्यास कोणताही अडथळा नाही. परिणाम तोच असतो. VPS वर Docker install करणे या समान कामाची Debian बाजू स्पष्ट करते. तेथे equivalent step source list आणि signing key दोन वेगवेगळ्या directories मध्ये लिहितो.

Repository मध्ये समस्या आल्यास कुठे पाहायचे हे layout मधील फरक ठरवतो. apt मध्ये definitions /etc/apt/sources.list आणि /etc/apt/sources.list.d/ मध्ये असतात आणि signing keys स्वतंत्रपणे /etc/apt/keyrings/ अंतर्गत ठेवलेल्या असतात. dnf मध्ये सर्वकाही /etc/yum.repos.d/ मध्ये असते. .repo file मध्ये key ची URL असते. त्यामुळे वाचण्यासाठी एकच file आणि delete करण्यासाठी एकच file असते. नवीन apt deb822 format मुळे त्याच रचनेकडे वळत आहे. प्रत्येक repository साठी एक .sources file असते. Ubuntu वरील deb822 duplicate sources error आल्यास तुम्ही या समस्येची apt बाजू आधीच पाहिलेली आहे.

EPEL हे बहुतांश मार्गदर्शक गृहीत धरतात ते archive आहे

Extra Packages for Enterprise Linux (EPEL) हा Fedora प्रकल्प आहे. तो RHEL आणि त्याच्या rebuilds साठी Fedora packages तयार करतो. या परिसंस्थेत universal PPA शी सर्वाधिक जवळची गोष्ट EPEL आहे. त्यामुळे अनेक tutorials मध्ये EPEL आधीपासून enabled आहे असे गृहीत धरले जाते. प्रकल्पाच्या स्वतःच्या website वर दिसणाऱ्या package साठी dnf install ने No match for argument असे उत्तर दिले असल्यास, सर्वप्रथम EPEL तपासा.

Rocky Linux आणि AlmaLinux वर:

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

CRB म्हणजे CodeReady Builder. हे libraries चे repository आहे. ते distribution सोबत येते, परंतु default नुसार enabled नसते. बहुतांश EPEL packages त्यातील एखाद्या घटकावर अवलंबून असतात. त्यामुळे CRB शिवाय EPEL enable केल्यास त्याच वेळी error येत नाही. Install करताना नंतर error येतो. तुम्ही कधीही ऐकले नसलेल्या package साठी unresolved dependencies दिसतात. आधी CRB enable करा. मग या प्रकारचा error येत नाही.

स्वतः RHEL वर CRB तुमच्या subscription द्वारे उपलब्ध होते; config-manager द्वारे नाही. त्यामुळे या टप्प्यासाठी Red Hat च्या स्वतःच्या EPEL instructions वापरा. Fedora ला यापैकी कशाचीही गरज नाही, कारण EPEL ज्या packages चे backport करते ते त्याच्या main repository मध्ये आधीपासून उपलब्ध असतात. EPEL policy नुसार RHEL कडून ships होणारा package कधीही replace केला जात नाही. त्यामुळे repository जोडल्याने तुमच्या server वर आधीपासून installed असलेल्या कोणत्याही गोष्टीत बदल होत नाही.

dnf history undo, apt मध्ये नसलेली सुविधा

dnf प्रत्येक transaction ची नोंद ठेवतो आणि त्याची उलट transaction तयार करू शकतो.

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

dnf history प्रत्येक transaction ची क्रमांकित यादी आणि ती सुरू करणारी command line दाखवते. undo त्या transaction ची उलट transaction तयार करते: transaction ने install केलेली packages remove केली जातात आणि upgrade केलेली packages तुमच्याकडे असलेल्या आवृत्तीवर परत नेली जातात. apt वापरकर्ते switch केल्यानंतर सर्वाधिक ज्या सुविधेची उणीव जाणवते, ती हीच आहे.

या सुविधेला प्रत्यक्ष मर्यादा आहेत. तिच्यावर अवलंबून राहण्यापूर्वी त्या जाणून घेणे महत्त्वाचे आहे. undo enabled repository मध्ये अजून उपलब्ध असलेली package versionच पुन्हा install करू शकते. त्यामुळे जुनी build mirror मधून काढून टाकल्यानंतर undo not-found error सह fail होते. Rollback package database पर्यंतच थांबते. Upgrade ने पुन्हा लिहिलेली config file तशीच rewritten राहते. सेवा पहिल्यांदा सुरू होताना migrate केलेला database schema देखील migrated अवस्थेतच राहतो. dnf files पूर्ववत ठेवते. तुमचा data पूर्ववत ठेवत नाही.

apt मध्ये याला समकक्ष सुविधा नाही. /var/log/apt/history.log नेमके काय घडले याची नोंद ठेवते, command line सहित; परंतु log वाचणे म्हणजे ते undo करणे नाही. apt-साठी recovery manually करावी लागते: archive मध्ये अजून कोणत्या versions उपलब्ध आहेत हे पाहण्यासाठी apt list -a nginx चालवा. त्यानंतर एखादी version pin करण्यासाठी sudo apt install nginx=<exact version string> वापरा आणि पुढील upgrade ने तुमचा fix undo करू नये म्हणून sudo apt-mark hold nginx जोडा.

Package groups साठी apt मध्ये समतुल्य सुविधा नाही

dnf एका command मध्ये packages चा नामांकित संच install करू शकतो.

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

जुन्या मार्गदर्शकांमध्ये dnf groupinstall "Development Tools" असे लिहिलेले आढळते. हा alias dnf 4 मध्ये चालतो, परंतु dnf 5 मध्ये काढून टाकण्यात आला आहे. त्यामुळे दोन शब्दांचा dnf group install हाच सर्व आवृत्त्यांमध्ये चालणारा एकमेव पर्याय आहे. तोच वापरा.

apt मध्ये groups नाहीत. Debian मध्ये यासारखी सर्वात जवळची संकल्पना metapackage आहे. हे अन्यथा रिकामे package असते आणि त्यामध्ये फक्त dependencies ची यादी असते; उदाहरणार्थ, build-essential. प्रत्यक्ष फरक काढून टाकताना दिसतो: metapackage काढल्यावर त्याच्या dependencies install राहतात आणि त्या काढण्यासाठी apt autoremove चालवावे लागते. त्याउलट, dnf group remove त्याच transaction मध्ये group मधील packages देखील काढतो.

unattended-upgrades आणि dnf-automatic

दोन्ही कुटुंबांमध्ये कोणीही login केलेले नसताना updates install करण्याची पद्धत आहे. त्यांचा उद्देश समान आहे; मात्र त्यांची साधने एकमेकांशी संबंधित नाहीत.

Ubuntu आणि Debian वर package चे नाव unattended-upgrades आहे. ते /etc/apt/apt.conf.d/50unattended-upgrades मध्ये configure केले जाते. या फाइलमध्ये कोणत्या origins मधून updates आणण्याची परवानगी आहे ते नमूद करता. Ubuntu वर unattended upgrades सेट करणे या लेखात ही configuration file आणि त्यासोबत येणाऱ्या reboot संबंधी प्रश्नाचे स्पष्टीकरण आहे.

Rocky Linux, AlmaLinux आणि Fedora वर package चे नाव dnf-automatic आहे. तुम्ही enable केलेला systemd timer त्याचे वर्तन ठरवतो.

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

dnf-automatic-install.timer updates download करून लागू करते. dnf-automatic-download.timer updates download करून थांबते; त्या install करण्याचे काम तुमच्याकडे राहते. dnf-automatic-notifyonly.timer फक्त अहवाल देते. यापैकी प्रत्येक unit /etc/dnf/automatic.conf मधील apply_updates setting override करते. त्यामुळे configuration file मध्ये काय लिहिले आहे यापेक्षा तुम्ही निवडलेला timer अधिक महत्त्वाचा असतो. Update install केल्यावर जुन्या code वर अद्याप चालू असलेली प्रक्रिया restart होत नाही. त्यामुळे server patched आहे असे गृहीत धरण्यापूर्वी यापैकी कोणत्या updates साठी reboot आणि कोणत्यासाठी फक्त service restart आवश्यक आहे हे तपासा.

फक्त security fixes पर्यंत ते मर्यादित ठेवण्यासाठी /etc/dnf/automatic.conf मध्ये upgrade_type = security सेट करा. हा filter तुमच्या repositories मध्ये security errata प्रकाशित केलेली आहेत यावर अवलंबून असतो. त्यामुळे प्रथम dnf updateinfo list security ने तपासा. Updates प्रलंबित असलेल्या server वर रिकामा result मिळाल्यास metadata उपलब्ध नाही असे समजा. अशा वेळी security काहीही install करणार नाही.

Fedora वर dnf 5 ने unit चे नाव बदलले आहे. ते dnf5-automatic.timer आहे आणि तेच /etc/dnf/automatic.conf वाचते.

yum अजूनही प्रत्यक्ष वापरातील command आहे का?

होय. तो स्वतःहून काहीही करत नाही. Rocky Linux, AlmaLinux आणि CentOS Stream वर /usr/bin/yum हा dnf कडे निर्देश करणारा symbolic link आहे. तुमच्या सिस्टमवर तो तपासा:

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

जुन्या yum syntax चा उल्लेख tutorials मध्ये अजूनही दिसतो, कारण त्यातील बहुतांश syntax थेट कार्यरत राहतो. yum install, yum remove आणि yum update हे सर्व कार्य करतात. मात्र एक सवय बदलणे योग्य आहे: dnf 4 systems वर yum-config-manager अजूनही स्वतंत्र binary म्हणून उपलब्ध आहे. परंतु सध्याच्या documentation मध्ये dnf config-manager हेच रूप वापरले जाते. सिस्टम dnf 5 वर गेल्यावरही हेच रूप कार्यरत राहते.

dnf 4 आणि dnf 5: command कॉपी करण्यापूर्वी तपासा

dnf 5 ही नव्याने लिहिलेली आवृत्ती आहे. त्यामुळे अनेक commands ची spelling बदलली आहे. Fedora 41 आणि त्यानंतरच्या आवृत्त्यांमध्ये ती dnf म्हणून उपलब्ध आहे. Enterprise rebuilds मध्ये बदल करण्यास अधिक वेळ लागला आहे. त्यामुळे distribution च्या नावावरून अंदाज लावू नका. तुमच्या सर्व्हरवर dnf --version चालवा आणि पहिली ओळ वाचा. त्या क्रमांकानुसार खालीलपैकी कोणती syntax वापरायची ते ठरते.

Docker हे याचे सर्वात स्पष्ट उदाहरण आहे. Docker प्रत्येक आवृत्तीसाठी वेगळी repository command प्रकाशित करते. RHEL आणि त्याच्या rebuilds वर dnf 4 वापरताना:

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

Fedora वर dnf 5 वापरताना:

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

Vendor तोच आहे आणि कामही तेच आहे. मात्र commands वेगळ्या आहेत. dnf 5 मध्ये config-manager चे रूपांतर subcommand-आधारित tool मध्ये झाले आहे. त्यामुळे जुना --add-repo flag स्वीकारला जात नाही. Repository तयार होण्याऐवजी usage error दिसतो. Repository enable करण्यासाठीही असाच फरक आहे: dnf 4 मधील dnf config-manager --set-enabled crb हे dnf 5 मध्ये dnf config-manager setopt crb.enabled=1 होते.

खरोखर महत्त्वाची निवड

फक्त package manager वरून server distribution निवडणे हा चुकीचा निकष आहे. dnf आणि apt एकच काम करतात, आणि त्यांची संज्ञा समजून घेण्यासाठी काही तास पुरेसे असतात. तुमच्या संपूर्ण वर्षावर परिणाम करणारी गोष्ट म्हणजे repository मागील release model. Fedora वेगाने बदलते आणि एखाद्या release ला तो उपलब्ध झाल्यानंतर साधारण तेरा महिन्यांनी updates मिळणे थांबते. workstation साठी हे योग्य आहे, परंतु पुन्हा build करायचा नसलेल्या server साठी ते त्रासदायक ठरते. Rocky Linux आणि AlmaLinux हे RHEL शी सुसंगतपणे पुढे जातात. त्यामुळे दहा वर्षांचा support window मिळतो आणि package versions जाणूनबुजून स्थिर ठेवले जातात. Ubuntu मध्ये दोन्ही प्रकार उपलब्ध आहेत. त्यामुळे server वर Ubuntu LTS आणि interim releases मधील फरक हा apt विश्वात घेतला जाणारा हाच निर्णय आहे.

August 2026 पर्यंत, हे सर्व सामान्य VPS images आहेत. तुम्हाला हवा असलेला support window निवडा आणि त्यानंतर वरील दहा commands शिका.

FAQ

apt update साठी dnf मधील समतुल्य काय आहे?

तुम्हाला कोणतीही स्वतंत्र command चालवण्याची गरज नाही. प्रत्येक transaction आधी dnf त्याच्या cache केलेल्या metadata चे वय तपासते आणि ते कालबाह्य झाले असल्यास नवीन प्रत डाउनलोड करते. त्यामुळे dnf install तुम्ही एखाद्या server ला महिनाभर हात लावला नसला तरी सध्याची packages दाखवते. sudo dnf makecache उपलब्ध आहे आणि ते download सक्तीने सुरू करते; परंतु त्याचा मुख्य उपयोग हा विलंब पुढील install मध्ये न होता तुमच्या निवडलेल्या वेळेला घडवून आणणे हा आहे. “माझ्यासाठी काय उपलब्ध आहे?” या प्रश्नाचे उत्तर देणारी command dnf check-update आहे. ती apt list --upgradable शी संबंधित आहे आणि updates उपलब्ध असल्यास status 100 सह समाप्त होते.

Rocky Linux किंवा Fedora मध्ये PPA चा समतुल्य पर्याय आहे का?

नाही. Personal package archives ही Launchpad ची service आहे आणि Launchpad ही Ubuntu ची infrastructure आहे. त्यामुळे add-apt-repository चे भाषांतर करण्यासाठी काहीही नाही. RPM मधील समतुल्य म्हणजे .repo file. ती /etc/yum.repos.d/ मध्ये ठेवली जाते आणि त्यात एक name, baseurl आणि gpgkey असतो. Vendors ही file तुमच्यासाठी publish करतात. त्यानंतर dnf 4 मध्ये sudo dnf config-manager --add-repo <url> किंवा dnf 5 मध्ये sudo dnf config-manager addrepo --from-repofile <url> ती योग्य ठिकाणी download करते. सर्वसाधारण अतिरिक्त software साठी नेहमीचा पर्याय EPEL असतो. तो enable करण्यासाठी sudo dnf config-manager --set-enabled crb आणि त्यानंतर sudo dnf install epel-release चालवा.

माझ्या server मध्ये बिघाड करणारे dnf upgrade पूर्ववत करता येईल का?

होय, काही मर्यादांसह. Transaction number शोधण्यासाठी sudo dnf history चालवा. त्यात नेमके कोणते बदल झाले ते पाहण्यासाठी sudo dnf history info <id> चालवा. त्यानंतर sudo dnf history undo <id> चालवा. Enabled repository मध्ये जुन्या package version ची कोणतीही प्रत उपलब्ध नसल्यास undo अयशस्वी होते, कारण dnf कडे पुन्हा install करण्यासाठी काहीही उपलब्ध नसते. ही प्रक्रिया फक्त package मधील बदल पूर्ववत करते. Upgrade ने पुन्हा लिहिलेली configuration file किंवा service प्रथम सुरू होताना migrate केलेला database तसाच राहतो. apt मध्ये यासाठी कोणतीही समतुल्य command नाही; फक्त /var/log/apt/history.log मधील record उपलब्ध असतो.

Rocky Linux आणि AlmaLinux वर yum अजूनही कार्य करते का?

होय, कारण /usr/bin/yum ही dnf कडे निर्देश करणारी symbolic link आहे. तुमच्या स्वतःच्या system वर ls -l /usr/bin/yum वापरून याची खात्री करा. yum install httpd टाइप केल्यास dnf चालते. त्यामुळे जुनी tutorials बहुतेक वेळा अजूनही कार्य करतात. नवीन scripts आणि documentation मध्ये dnf वापरा, कारण yum हे नाव फक्त compatibility साठी आहे. तसेच जुन्या yum-config-manager binary ऐवजी dnf config-manager ला प्राधान्य द्या.

dnf remove ला इतकी packages हटवायची गरज का भासते?

कारण त्याच transaction चा भाग म्हणून dnf अशा dependencies हटवते ज्यांची इतर कोणत्याही package ला गरज नसते. याउलट apt remove त्या dependencies तुम्ही स्वतंत्रपणे apt autoremove चालवेपर्यंत installed ठेवते. त्यामुळे Ubuntu वर लहान दिसणाऱ्या removal मुळे Rocky Linux वर मोठी यादी दिसू शकते. ही यादी सामान्यतः योग्य असते; तरीही confirmation देण्यापूर्वी ती वाचा. यादीतील एखादी package तुम्हाला ठेवायची असल्यास ती आधी explicitly install करा. त्यामुळे dnf तिला स्वतंत्रपणे आवश्यक असलेली package म्हणून नोंदवते.