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

थोडक्यात

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

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

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

Fedora, Red Hat Enterprise Linux (RHEL) आणि RHEL चे पुनर्बांधित distros 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 मिळते.

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 समतुल्य

Install, remove, search आणि show. दोन्ही बाजूंवर यांसाठी जवळपास समान शब्द वापरले जातात.

# 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. या गटातील rename केलेला हा एकमेव verb आहे. मात्र एक वर्तन वेगळे आहे आणि त्यामुळे अनेकांना समस्या येते. dnf remove अशा dependencies देखील काढून टाकते ज्यांची गरज इतर कोणत्याही गोष्टीला नाही. त्याउलट, apt remove त्या dependencies नंतरच्या apt autoremove साठी installed ठेवते. त्यामुळे Rocky Linux वर एखादी लहान utility काढताना तिच्यासोबत डझनभर libraries काढण्याचा प्रस्ताव दिसू शकतो. Confirm करण्यापूर्वी यादी वाचा.

Metadata refresh करा, कोणती updates प्रतीक्षेत आहेत ते तपासा आणि 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 disk वर उपलब्ध असलेले metadata वापरते आणि archive मधून अनेक महिन्यांपूर्वी काढून टाकलेली version देखील install करू शकते. प्रत्येक transaction पूर्वी dnf त्याच्या cache चे वय तपासते आणि fresh metadata स्वतः download करते. त्यामुळे पुढील install दरम्यान download करण्याऐवजी तो download आत्ताच करण्यास भाग पाडण्यासाठी sudo dnf makecache वापरले जाते.

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

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

काय installed आहे ते list करा आणि एखाद्या 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 मधील शेवटची line तिच्यापूर्वीच्या lines पेक्षा वेगळ्या प्रश्नाचे उत्तर देते. dpkg -S आणि rpm -qf फक्त आधीपासून installed असलेल्या packages मध्ये search करतात. त्यामुळे ते “ही file येथे कशामुळे आली” याचे उत्तर देतात. apt-file search आणि dnf provides repositories मध्ये search करतात. त्यामुळे ते “ही file मिळवण्यासाठी कोणते package install करावे लागेल” याचे उत्तर देतात. apt-file हे Ubuntu वर स्वतंत्र package आहे आणि पहिल्यांदा चालवण्यापूर्वी sudo apt-file update आवश्यक आहे. dnf provides ला अतिरिक्त काहीही आवश्यक नाही. मात्र पहिल्यांदा चालवताना ते धीमे असू शकते, कारण उत्तर देण्यासाठी dnf repository च्या file lists download करते.

तुम्ही अद्याप install न केलेल्या package मधील files list करण्यासाठी 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 ने installed नसते. त्यामुळे fresh box वर त्यातील पहिली line No such command: versionlock सह fail होते. प्रथम sudo dnf install python3-dnf-plugin-versionlock वापरून ते install करा. apt-mark hold साठी apt ला अतिरिक्त काहीही आवश्यक नाही, कारण hold ही plugin ची नव्हे तर dpkg state ची बाब आहे.

मॅपिंग कुठे अपयशी ठरते: repository जोडणे

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

dnf मध्ये त्याऐवजी प्रत्येक repository साठी /etc/yum.repos.d/ मध्ये एक साधी 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 प्रकाशित करतात आणि ती fetch करण्यास सांगतात. RHEL आणि त्याच्या rebuilds साठी Docker च्या स्वतःच्या सूचनांमध्ये दोन 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 सह अपयशी ठरते. तीच .repo file curl वापरून स्वतः download करून /etc/yum.repos.d/ मध्ये ठेवण्यापासून तुम्हाला कोणीही रोखत नाही. परिणाम समान असतो. VPS वर Docker install करणे याच कामाची Debian बाजू स्पष्ट करते. तेथे समतुल्य पायरी 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/ मध्ये असते. Key ही .repo file मधील URL असते. त्यामुळे वाचण्यासाठी एक file आणि हटवण्यासाठी एक 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 आहे. त्यामुळे अनेक tutorial मध्ये 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. हे distribution सोबत येणाऱ्या libraries चे repository आहे; मात्र ते default ने enabled नसते. बहुतेक EPEL packages त्यातील एखाद्या गोष्टीवर अवलंबून असतात. त्यामुळे CRB शिवाय EPEL enable केल्यावर लगेच error येत नाही. नंतर install करताना, तुम्ही कधीही ऐकले नसलेल्या package साठी unresolved dependencies आल्यामुळे ते अपयशी ठरते. प्रथम CRB enable करा. त्यामुळे या प्रकारची error दूर होते.

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

dnf history undo, जे apt करू शकत नाही

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

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

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

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

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

पॅकेज गटांना apt मध्ये समतुल्य पर्याय नाही

dnf एकाच आदेशात पॅकेजांचा नावाने निर्दिष्ट केलेला संच स्थापित करू शकतो.

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 मध्ये गट नाहीत. Debian मधील याच्या सर्वात जवळची संकल्पना metapackage ही आहे. हे अन्यथा रिकामे असलेले पॅकेज असून त्यात फक्त dependencies ची यादी असते, जसे build-essential. प्रत्यक्ष फरक काढून टाकताना दिसतो: metapackage काढल्यावर त्याच्या dependencies स्थापितच राहतात, जोपर्यंत तुम्ही apt autoremove चालवत नाही. त्याउलट, dnf group remove त्याच व्यवहारात त्या गटातील पॅकेजेसह काढून टाकते.

unattended-upgrades आणि dnf-automatic

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

Ubuntu आणि Debian वर package `unattended-upgrades आहे. त्याची configuration /etc/apt/apt.conf.d/50unattended-upgrades` मध्ये असते. या फाइलमध्ये updates कोणत्या origins मधून आणण्याची परवानगी आहे ते नमूद करता. 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 अधिक महत्त्वाचा असतो.

हे security fixes पुरते मर्यादित ठेवण्यासाठी `/etc/dnf/automatic.conf मध्ये upgrade_type = security सेट करा. हा filter तुमच्या repositories मध्ये security errata प्रकाशित केलेले असण्यावर अवलंबून असतो. त्यामुळे प्रथम dnf updateinfo list security वापरून तपासा. Updates प्रलंबित असलेल्या system वर रिकामा 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

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

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

dnf 5 ही नव्याने लिहिलेली आवृत्ती आहे. त्यामुळे अनेक commands चे spelling बदलले आहे. Fedora 41 आणि त्यानंतरच्या आवृत्त्यांमध्ये ते dnf म्हणून दिले जाते. Enterprise rebuilds मध्ये बदल करण्यास अधिक वेळ लागला आहे. त्यामुळे distribution च्या नावावरून अंदाज लावू नका. तुमच्या server वर 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 साठी हे योग्य आहे; परंतु पुन्हा तयार करायचा नसलेल्या 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 त्याच्या cached metadata चे वय तपासते. ते कालबाह्य झाले असल्यास dnf नवीन प्रत डाउनलोड करते. त्यामुळे 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 चे समतुल्य म्हणजे /etc/yum.repos.d/ मधील .repo file. त्यात 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 असते. ते sudo dnf config-manager --set-enabled crb नंतर sudo dnf install epel-release चालवून enable करता येते.

dnf upgrade मुळे server बिघडल्यास ते पूर्ववत करता येते का?

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

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

होय. कारण /usr/bin/yum ही dnf कडे निर्देश करणारी symbolic link आहे. तुमच्या स्वतःच्या box वर 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 हटवते ज्यांची इतर कोणत्याही गोष्टीला गरज नसते. याउलट, apt remove त्या packages तुम्ही स्वतंत्रपणे apt autoremove चालवेपर्यंत installed ठेवते. त्यामुळे Ubuntu वर छोटी दिसणारी removal Rocky Linux वर मोठी list दाखवू शकते. ही list सहसा योग्य असते, तरी confirm करण्यापूर्वी ती वाचा. त्यातील एखादी package तुम्हाला ठेवायची असल्यास ती आधी explicitly install करा. त्यामुळे dnf तिची स्वतंत्रपणे आवश्यक package म्हणून नोंद करते.