apt commands का dnf equivalent: Rocky और Fedora गाइड

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

apt से dnf पर जाना मुख्य रूप से शब्दावली का बदलाव है। apt install nginx अब dnf install nginx बन जाता है। apt remove nginx अब dnf remove nginx बन जाता है। apt update का कोई सीधा विकल्प नहीं है, क्योंकि dnf cached copy पुरानी होने पर अपने आप repository metadata को refresh कर लेता है। अनुवाद का आसान हिस्सा एक स्क्रीन में आ जाता है। उपयोगी हिस्सा वे चार operations हैं जिनका कोई सीधा मेल नहीं है: repository जोड़ना, transaction को undo करना, package group install करना, और unattended updates चलाना।

नीचे दिया गया प्रत्येक command आपके अपने सर्वर पर चलाने के लिए लिखा गया है। y का उत्तर देने से पहले dnf द्वारा प्रिंट किए गए transaction summary को ध्यान से पढ़ें, विशेषकर removals के समय।

किन distros में dnf का उपयोग होता है, और किन में apt का

dnf, Fedora, Red Hat Enterprise Linux (RHEL) और RHEL के rebuilds जैसे Rocky Linux, AlmaLinux और CentOS Stream पर package manager है। apt, Debian और Debian से व्युत्पन्न सभी distros पर 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 है। यह इस समूह में एकमात्र renamed verb है, लेकिन एक व्यवहार अलग है जो लोगों को भ्रमित करता है। dnf remove उन dependencies को भी हटा देता है जिनकी किसी और को आवश्यकता नहीं है, जबकि apt remove उन्हें बाद के apt autoremove के लिए install रहने देता है। इसलिए Rocky Linux पर एक छोटी utility को हटाने से एक दर्जन libraries भी हट सकती हैं। पुष्टि करने से पहले सूची को ध्यान से पढ़ें।

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 का उपयोग करता है और खुशी-खुशी वह version install कर देगा जो महीनों पहले archive से हट चुका है। dnf हर transaction से पहले अपने cache की age की जाँच करता है और स्वयं fresh metadata download करता है, इसलिए sudo dnf makecache का उपयोग केवल तब किया जाता है जब आप अगली install की प्रतीक्षा किए बिना अभी download करना चाहते हैं।

apt पूरे system upgrade को दो भागों में विभाजित करता है, जबकि dnf ऐसा नहीं करता है। apt upgrade किसी भी installed package को हटाने से मना कर देता है, इसलिए जब किसी update के लिए किसी package को हटाना आवश्यक होता है, तो यह रुक जाता है। apt full-upgrade वह version है जिसे हटाने की अनुमति है। dnf में ऐसा कोई प्रतिबंध नहीं है, जिसका अर्थ है कि dnf upgrade, apt upgrade का नहीं, बल्कि apt full-upgrade का समकक्ष है। dnf update उसी कमांड के लिए एक पुराना alias है और अभी भी काम करता है।

यदि आप इसे script कर रहे हैं तो एक विवरण मायने रखता है: जब updates लंबित होते हैं तो dnf check-update status 100 के साथ exit होता है और जब कोई update नहीं होता तो 0 के साथ। apt list --upgradable दोनों स्थितियों में 0 के साथ exit होता है, इसलिए scripts को इसके output को parse करना पड़ता है।

सूची देखें कि क्या installed है, और पता लगाएँ कि कौन सा package किसी file का स्वामी है।

# 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 केवल उन packages को search करते हैं जो पहले से installed हैं, इसलिए वे उत्तर देते हैं कि "इस file को यहाँ किसने रखा"। apt-file search और dnf provides repositories को search करते हैं, इसलिए वे उत्तर देते हैं कि "इस file को पाने के लिए मुझे क्या install करना चाहिए"। apt-file Ubuntu पर एक अलग package है और इसे पहली बार चलाने से पहले sudo apt-file update की आवश्यकता होती है। dnf provides को किसी अतिरिक्त चीज़ की आवश्यकता नहीं है, हालाँकि पहली बार चलाने पर यह धीमा हो सकता है क्योंकि dnf उत्तर देने के लिए repository file lists को download करता है।

किसी ऐसे package के अंदर की files को सूचीबद्ध करने के लिए जिसे आपने अभी तक install नहीं किया है, dnf repoquery -l nginx का उपयोग करें। apt की तरफ यह apt-file list nginx है।

Autoremove, cache को clean करें, 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

versionlock, Rocky Linux या AlmaLinux पर default रूप से install नहीं होता है, इसलिए उन पंक्तियों में से पहली पंक्ति एक नए box पर No such command: versionlock के साथ विफल हो जाती है। इसे पहले sudo dnf install python3-dnf-plugin-versionlock के साथ install करें। apt को apt-mark hold के लिए किसी अतिरिक्त चीज़ की आवश्यकता नहीं है, क्योंकि hold एक dpkg state है न कि कोई plugin।

मैपिंग कहाँ विफल होती है: रिपॉजिटरी जोड़ना

यह वह हिस्सा है जो Ubuntu एडमिनिस्ट्रेटर को एक ऐसे कमांड की तलाश में लगा देता है जो मौजूद ही नहीं है। dnf में कोई add-apt-repository नहीं होता है, और न ही कोई पर्सनल पैकेज आर्काइव (PPA) होते हैं। PPA, Launchpad द्वारा संचालित एक सेवा है, और Launchpad Ubuntu का इंफ्रास्ट्रक्चर है। RPM की दुनिया में ऐसा कुछ भी होस्ट नहीं किया जाता है।

इसके बजाय, dnf में /etc/yum.repos.d/ में प्रत्येक रिपॉजिटरी के लिए एक सादा टेक्स्ट फ़ाइल होती है, जो .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 वेरिएबल्स हैं। dnf रनटाइम पर आपके मेजर रिलीज़ नंबर और CPU आर्किटेक्चर को भर देता है, इसलिए वही फ़ाइल वर्ज़न 9 और वर्ज़न 10, तथा x86_64 और aarch64 दोनों पर काम करती है।

अधिकांश वेंडर उस फ़ाइल को पब्लिश करते हैं और आपको उसे फेच (fetch) करने के लिए कहते हैं। RHEL और इसके रीबिल्ड्स के लिए Docker के अपने निर्देश दो कमांड हैं:

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

पहली लाइन इसलिए है क्योंकि config-manager एक प्लगइन है, न कि dnf का हिस्सा। इसे छोड़ दें तो दूसरी लाइन No such command: config-manager के साथ विफल हो जाएगी। आपको उस समान .repo फ़ाइल को curl के साथ मैन्युअल रूप से /etc/yum.repos.d/ में डाउनलोड करने से कोई नहीं रोकता, और परिणाम बिल्कुल समान होता है। VPS पर Docker इंस्टॉल करना इसी कार्य के Debian पक्ष को बताता है, जहाँ समकक्ष चरण एक सोर्स लिस्ट और एक साइनिंग की (signing key) को दो अलग-अलग डायरेक्टरी में लिखता है।

लेआउट का अंतर यह तय करता है कि रिपॉजिटरी के खराब व्यवहार करने पर आपको कहाँ देखना है। apt परिभाषाओं को /etc/apt/sources.list और /etc/apt/sources.list.d/ में रखता है, जबकि साइनिंग की (signing keys) को /etc/apt/keyrings/ के अंतर्गत अलग से रखा जाता है। dnf सब कुछ /etc/yum.repos.d/ में रखता है, और की (key) .repo फ़ाइल के अंदर एक URL होती है, इसलिए पढ़ने के लिए एक फ़ाइल और हटाने के लिए एक फ़ाइल होती है। नए apt ने deb822 फॉर्मेट के साथ इसी आकार को अपना लिया है, जिसमें प्रति रिपॉजिटरी एक .sources फ़ाइल होती है। यदि आपको Ubuntu पर deb822 डुप्लिकेट सोर्स एरर का सामना करना पड़ा है, तो आप इस समस्या के apt वाले हिस्से से पहले ही मिल चुके हैं।

EPEL वह आर्काइव है जिसे अधिकांश गाइड्स मानकर चलती हैं

Extra Packages for Enterprise Linux (EPEL) एक Fedora प्रोजेक्ट है जो RHEL और इसके rebuilds के लिए Fedora packages बनाता है। यह इस दुनिया में universal PPA के सबसे करीब है, और बड़ी संख्या में ट्यूटोरियल यह मानकर चलते हैं कि यह पहले से enabled है। यदि dnf install किसी ऐसे package के लिए 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 के साथ आती हैं लेकिन डिफ़ॉल्ट रूप से enabled नहीं होती हैं। अधिकांश EPEL packages इसमें मौजूद किसी न किसी चीज़ पर निर्भर करते हैं, इसलिए CRB के बिना EPEL को enable करने पर उस समय तो कोई error नहीं आता। यह बाद में, install करते समय, किसी ऐसे package पर unresolved dependencies के साथ fail होता है जिसके बारे में आपने कभी नहीं सुना होगा। पहले CRB को enable करें और उस प्रकार की error समाप्त हो जाएगी।

स्वयं RHEL पर, CRB आपके subscription के माध्यम से आता है, न कि config-manager के माध्यम से, इसलिए उस चरण के लिए Red Hat के अपने EPEL निर्देशों का पालन करें। Fedora को इसकी आवश्यकता नहीं है, क्योंकि इसके मुख्य repository में पहले से ही वह सब होता है जिसे EPEL backport करता है। EPEL की नीति यह है कि वह कभी भी उस package को replace नहीं करता जिसे RHEL शिप करता है, इसलिए repository जोड़ने से आपके सर्वर पर पहले से इंस्टॉल किसी भी चीज़ में कोई बदलाव नहीं आता है।

dnf history undo, वह सुविधा जो apt में नहीं है

dnf हर transaction का रिकॉर्ड रखता है और यह किसी भी transaction को उलटने (reverse) की क्षमता रखता है।

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

dnf history उन transactions की एक क्रमांकित सूची दिखाता है जिन्हें command line के माध्यम से शुरू किया गया था। undo विपरीत transaction तैयार करता है: जिन packages को उस transaction ने install किया था, उन्हें हटा दिया जाता है, और जिन packages को upgrade किया गया था, वे पुरानी version पर वापस आ जाते हैं। यह वह सुविधा है जिसे apt users dnf पर स्विच करने के बाद सबसे अधिक याद करते हैं।

इसकी कुछ वास्तविक सीमाएँ हैं, जिन्हें इस पर निर्भर होने से पहले जानना आवश्यक है। undo केवल उसी package version को फिर से install कर सकता है जो किसी enabled repository में मौजूद हो। इसलिए, एक बार जब पुराना build mirror से हटा दिया जाता है, तो undo प्रक्रिया not-found error के साथ विफल हो जाती है। Rollback केवल package database तक ही सीमित रहता है। यदि upgrade के दौरान किसी config file को rewrite किया गया था, तो वह वैसी ही रहेगी, और यदि किसी service ने पहली बार start होने पर database schema को migrate किया था, तो वह भी migrate ही रहेगा। dnf केवल files को वापस लाता है, यह आपके data को वापस नहीं लाता।

apt में इसका कोई समकक्ष नहीं है। /var/log/apt/history.log केवल यह रिकॉर्ड करता है कि क्या हुआ था, जिसमें command line भी शामिल है, लेकिन log पढ़ना उसे undo करना नहीं है। apt-side पर recovery मैन्युअल है: यह देखने के लिए कि archive में कौन से versions अभी भी उपलब्ध हैं, apt list -a nginx चलाएँ, फिर किसी एक को pin करने के लिए sudo apt install nginx=<exact version string> का उपयोग करें, और sudo apt-mark hold nginx जोड़ें ताकि अगला upgrade आपके द्वारा किए गए सुधार को न हटा दे।

Package groups का कोई apt समकक्ष नहीं है

dnf एक ही command में packages के एक नामित समूह को install कर सकता है।

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

पुराने guides में dnf groupinstall "Development Tools" लिखा जाता है। यह alias dnf 4 पर काम करता है, लेकिन dnf 5 पर यह उपलब्ध नहीं है, इसलिए दो शब्दों वाला dnf group install ही एकमात्र spelling है जो हर जगह काम करती है। इसका उपयोग करें और इसके बारे में अधिक न सोचें।

apt में groups नहीं होते हैं। Debian में इसके सबसे करीब metapackage की अवधारणा है, जो एक खाली package होता है जिसका एकमात्र कार्य dependencies की सूची रखना है, जैसे कि build-essential। व्यावहारिक अंतर यह है कि metapackage को remove करने पर उसकी dependencies तब तक install रहती हैं जब तक आप apt autoremove नहीं चलाते, जबकि dnf group remove एक ही transaction में group के सभी packages को हटा देता है।

unattended-upgrades और dnf-automatic

ये दोनों परिवार बिना किसी user के login हुए updates install करने का तरीका प्रदान करते हैं। इन tools का उद्देश्य एक ही है, लेकिन इनके बीच कोई समानता नहीं है।

Ubuntu और Debian पर इसके लिए unattended-upgrades package का उपयोग होता है, जिसे /etc/apt/apt.conf.d/50unattended-upgrades में configure किया जाता है। यहाँ आप उन origins की सूची देते हैं जिनसे updates लिए जा सकते हैं। Ubuntu पर unattended upgrades सेट करना उस config file और उससे जुड़े reboot के सवाल को विस्तार से समझाता है।

Rocky Linux, AlmaLinux और Fedora पर इसके लिए dnf-automatic package का उपयोग होता है, और आप जिस systemd timer को enable करते हैं, वही इसके व्यवहार को निर्धारित करता है।

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

dnf-automatic-install.timer updates को download और apply करता है। dnf-automatic-download.timer उन्हें केवल download करता है और रुक जाता है, जिससे install करने का काम आप पर रहता है। dnf-automatic-notifyonly.timer केवल रिपोर्ट देता है। इनमें से प्रत्येक unit /etc/dnf/automatic.conf में मौजूद apply_updates setting को override कर देती है, इसलिए config file में क्या लिखा है, उससे कहीं अधिक महत्वपूर्ण यह है कि आप कौन सा timer चुनते हैं।

इसे केवल security fixes तक सीमित रखने के लिए, /etc/dnf/automatic.conf में upgrade_type = security set करें। यह filter इस बात पर निर्भर करता है कि आपकी repositories security errata प्रकाशित करती हैं या नहीं, इसलिए पहले dnf updateinfo list security के साथ इसकी जाँच करें। यदि किसी server पर updates pending हैं और फिर भी परिणाम खाली आता है, तो इसका मतलब है कि metadata उपलब्ध नहीं है, और ऐसी स्थिति में security कुछ भी install नहीं करेगा।

Fedora पर, dnf 5 ने इस unit का नाम बदल दिया है। अब यह dnf5-automatic.timer है, और यह उसी /etc/dnf/automatic.conf को पढ़ता है।

क्या yum अभी भी एक वास्तविक command है?

हाँ, और यह अपने आप में कुछ नहीं करता है। Rocky Linux, AlmaLinux और CentOS Stream पर, /usr/bin/yum एक symbolic link है जो dnf की ओर इशारा करता है। अपना चेक करें:

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

पुराना yum syntax tutorials में दिखाई देता रहता है क्योंकि इसका अधिकांश हिस्सा अभी भी सीधे काम करता है। yum install, yum remove और yum update सभी काम करते हैं। एक आदत जिसे छोड़ देना चाहिए: yum-config-manager अभी भी dnf 4 systems पर अपनी binary के रूप में मौजूद है, लेकिन dnf config-manager वह spelling है जिसका उपयोग वर्तमान documentation में किया जाता है, और यह वही है जो box के dnf 5 पर जाने पर भी काम करता रहता है।

dnf 4 और dnf 5: कमांड कॉपी करने से पहले जाँचें

dnf 5 एक नया rewrite है, और इसने कई कमांड्स के spelling बदल दिए हैं। Fedora 41 और उसके बाद के वर्ज़न इसे dnf के रूप में ship करते हैं। Enterprise rebuilds ने इसे अपनाने में अधिक समय लिया है, इसलिए distribution के नाम से अनुमान न लगाएँ। अपने सर्वर पर dnf --version चलाएँ और पहली पंक्ति पढ़ें, क्योंकि वही संख्या तय करती है कि आपको नीचे दी गई कौन सी syntax की आवश्यकता है।

इसका सबसे स्पष्ट उदाहरण Docker है, जो प्रत्येक के लिए अलग repository कमांड प्रकाशित करता है। 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, वही काम, लेकिन शब्द अलग। dnf 5 ने config-manager को एक subcommand-आधारित टूल में बदल दिया है, इसलिए पुराना --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 आने के लगभग तेरह महीने बाद अपडेट मिलना बंद हो जाता है। यह workstation के लिए तो ठीक है, लेकिन ऐसे server के लिए कष्टदायक है जिसे आप बार-बार rebuild नहीं करना चाहते। Rocky Linux और AlmaLinux, RHEL को ट्रैक करते हैं, इसलिए आपको दस साल की support window और ऐसे package versions मिलते हैं जो जानबूझकर स्थिर रहते हैं। Ubuntu दोनों विकल्प प्रदान करता है, और server पर Ubuntu LTS और interim releases के बीच का अंतर वही निर्णय है जो apt की दुनिया के भीतर लिया जाता है।

अगस्त 2026 तक, ये सभी सामान्य VPS images हैं। वह support window चुनें जो आप चाहते हैं, फिर ऊपर दिए गए दस commands सीखें।

FAQ

apt update का dnf समकक्ष क्या है?

आपको कोई कमांड चलाने की आवश्यकता नहीं है। dnf हर ट्रांजेक्शन से पहले यह जाँचता है कि उसका cached metadata कितना पुराना है और एक्सपायर होने पर एक नई कॉपी डाउनलोड कर लेता है, इसलिए जिस सर्वर को आपने एक महीने से नहीं छुआ है, उस पर भी dnf install चलाने पर आपको वर्तमान पैकेज ही दिखेंगे। sudo dnf makecache मौजूद है और यह उस डाउनलोड को बाध्य (force) करता है, लेकिन इसका वास्तविक उपयोग देरी को उस समय पर ले जाना है जिसे आप चुनते हैं, न कि आपके अगले इंस्टॉलेशन के समय। जो कमांड यह बताती है कि "मेरे लिए क्या अपडेट उपलब्ध है", वह dnf check-update है, जो apt list --upgradable के समान है और अपडेट उपलब्ध होने पर 100 स्टेटस के साथ समाप्त (exit) होती है।

क्या Rocky Linux या Fedora पर PPA का कोई समकक्ष है?

नहीं। Personal package archives एक Launchpad सेवा है और Launchpad Ubuntu का इंफ्रास्ट्रक्चर है, इसलिए add-apt-repository के लिए कोई अनुवाद मौजूद नहीं है। RPM समकक्ष /etc/yum.repos.d/ में स्थित एक .repo फाइल है, जिसमें नाम, baseurl और gpgkey होता है। वेंडर आपके लिए वह फाइल प्रकाशित करते हैं, और dnf 4 पर sudo dnf config-manager --add-repo <url>, या dnf 5 पर sudo dnf config-manager addrepo --from-repofile <url>, उसे डाउनलोड करके सही स्थान पर रख देता है। सामान्य अतिरिक्त सॉफ्टवेयर के लिए उत्तर आमतौर पर EPEL है, जिसे आप sudo dnf config-manager --set-enabled crb और उसके बाद sudo dnf install epel-release चलाकर सक्षम (enable) करते हैं।

क्या मैं dnf upgrade को पूर्ववत (undo) कर सकता हूँ जिसने मेरे सर्वर को खराब कर दिया?

हाँ, सीमाओं के भीतर। ट्रांजेक्शन नंबर खोजने के लिए sudo dnf history चलाएँ, यह देखने के लिए कि उसने वास्तव में क्या बदला है sudo dnf history info <id> चलाएँ, और फिर sudo dnf history undo <id> का उपयोग करें। यदि पुराना पैकेज संस्करण किसी भी सक्षम रिपॉजिटरी में मौजूद नहीं है, तो undo विफल हो जाता है, क्योंकि dnf के पास फिर से इंस्टॉल करने के लिए कुछ नहीं होता है। यह केवल पैकेज परिवर्तनों को ही उलटता है। अपग्रेड द्वारा फिर से लिखी गई कॉन्फ़िगरेशन फाइल, या पहली बार शुरू होने पर किसी सेवा द्वारा माइग्रेट किया गया डेटाबेस, वैसा ही रहता है जैसा वह है। apt में इसके समकक्ष कोई कमांड नहीं है, केवल /var/log/apt/history.log में रिकॉर्ड होता है।

क्या Rocky Linux और AlmaLinux पर yum अभी भी काम करता है?

यह काम करता है क्योंकि /usr/bin/yum, dnf का एक symbolic link है। इसे अपने बॉक्स पर ls -l /usr/bin/yum के साथ पुष्टि करें। yum install httpd टाइप करने पर dnf ही चलता है, इसलिए पुराने ट्यूटोरियल अधिकतर अभी भी काम करते हैं। नई स्क्रिप्ट और दस्तावेज़ dnf के साथ लिखें, क्योंकि yum नाम केवल संगतता (compatibility) के लिए है, और पुराने yum-config-manager बाइनरी के बजाय dnf config-manager को प्राथमिकता दें।

dnf remove इतने सारे पैकेज क्यों हटाना चाहता है?

क्योंकि dnf उसी ट्रांजेक्शन के हिस्से के रूप में उन dependencies को हटा देता है जिनकी अब किसी और को आवश्यकता नहीं है, जबकि apt remove उन्हें तब तक इंस्टॉल रखता है जब तक आप अलग से apt autoremove नहीं चलाते। इसलिए Ubuntu पर जो रिमूवल छोटा दिखता है, वह Rocky Linux पर एक लंबी सूची दिखा सकता है। यह सूची आमतौर पर सही होती है, लेकिन पुष्टि करने से पहले इसे पढ़ें। यदि सूची में कोई ऐसा पैकेज है जिसे आप रखना चाहते हैं, तो उसे पहले स्पष्ट रूप से इंस्टॉल करें ताकि dnf उसे अपनी आवश्यकता के अनुसार रिकॉर्ड कर ले।