apt commands का dnf में अनुवाद: Rocky और Fedora गाइड

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

apt से dnf पर जाना मुख्य रूप से शब्दावली में बदलाव है। apt install nginx अब dnf install nginx बन जाता है। apt remove nginx अब dnf remove nginx बन जाता है। apt update का कोई सीधा विकल्प नहीं है, क्योंकि जब cached copy पुरानी हो जाती है तो dnf अपने आप 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 से व्युत्पन्न (derived) सभी systems पर package manager है, जिसका VPS के संदर्भ में लगभग हमेशा मतलब Ubuntu होता है। इसके अलावा कोई तीसरा विकल्प नहीं है। यदि आपके provider की image list में Rocky Linux या AlmaLinux है, तो आप dnf का उपयोग करेंगे। यदि इसमें Ubuntu है, तो आप apt का उपयोग करेंगे। इस विभाजन के एक तरफ एक ही system के लिए चार नाम क्यों हैं, यह जानना आपके लिए उपयोगी है, और Red Hat Linux कैसे Fedora, RHEL, CentOS, Rocky और AlmaLinux बना यह समझाता है कि प्रत्येक की उत्पत्ति कहाँ से हुई है।

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 है। इस समूह में केवल यही क्रिया (verb) बदली गई है, लेकिन एक व्यवहार अलग है जो लोगों को भ्रमित करता है। dnf remove उन dependencies को भी हटा देता है जिनकी अब किसी और को आवश्यकता नहीं है, जबकि apt remove उन्हें बाद में किसी apt autoremove के लिए इंस्टॉल रहने देता है। इसलिए Rocky Linux पर एक छोटी utility को हटाने से एक दर्जन libraries भी हट सकती हैं। पुष्टि करने से पहले सूची को ध्यान से पढ़ें।

Metadata को रिफ्रेश करें, देखें कि क्या अपडेट लंबित है, और अपग्रेड करें।

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

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

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

इंस्टॉल किए गए पैकेज की सूची देखें, और पता लगाएँ कि किस पैकेज के पास कोई फाइल है।

# 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

प्रत्येक ब्लॉक की अंतिम पंक्ति ऊपर दिए गए प्रश्नों से अलग प्रश्न का उत्तर देती है। dpkg -S और rpm -qf केवल उन पैकेजों को खोजते हैं जो पहले से इंस्टॉल हैं, इसलिए वे इस प्रश्न का उत्तर देते हैं कि "इस फाइल को यहाँ किसने रखा"। apt-file search और dnf provides repositories को खोजते हैं, इसलिए वे इस प्रश्न का उत्तर देते हैं कि "इस फाइल को पाने के लिए मुझे क्या इंस्टॉल करना चाहिए"। apt-file Ubuntu पर एक अलग पैकेज है और इसे पहली बार चलाने से पहले sudo apt-file update की आवश्यकता होती है। dnf provides को किसी अतिरिक्त चीज़ की आवश्यकता नहीं होती, हालाँकि पहली बार चलाने पर यह धीमा हो सकता है क्योंकि dnf उत्तर देने के लिए repository फाइल सूचियों को डाउनलोड करता है।

उन पैकेजों के अंदर की फाइलों को सूचीबद्ध करने के लिए जिन्हें आपने अभी तक इंस्टॉल नहीं किया है, 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

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

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

यह वह हिस्सा है जो Ubuntu एडमिन्स को एक ऐसे कमांड की तलाश में लगा देता है जो मौजूद ही नहीं है। dnf में कोई add-apt-repository नहीं होता है, और न ही कोई personal package archives (PPAs) होते हैं। 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/ में रखता है, जबकि साइनिंग कीज़ को /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 की नीति यह है कि वह RHEL द्वारा ship किए गए किसी भी package को कभी नहीं बदलता है, इसलिए 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 को reinstall कर सकता है जो अभी भी किसी enabled repository में मौजूद है, इसलिए एक बार जब पुराना build mirror से हटा दिया जाता है, तो undo प्रक्रिया not-found error के साथ विफल हो जाती है। Rollback केवल package database तक ही सीमित रहता है। upgrade के दौरान rewrite की गई config file वैसी ही रहती है, और पहली बार start होने पर service द्वारा migrate किया गया database schema भी migrate ही रहता है। dnf केवल files को वापस लाता है। यह आपके डेटा को वापस नहीं लाता है।

apt में इसका कोई समकक्ष नहीं है। /var/log/apt/history.log ठीक वही रिकॉर्ड करता है जो हुआ था, जिसमें command line भी शामिल है, लेकिन log पढ़ना उसे उलटना नहीं है। apt-side पर रिकवरी मैन्युअल है: यह देखने के लिए कि 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

ये दोनों परिवार बिना किसी यूजर के लॉग इन हुए अपडेट इंस्टॉल करने का तरीका प्रदान करते हैं। इन टूल्स का उद्देश्य एक ही है, लेकिन इनके बीच कोई समानता नहीं है।

Ubuntu और Debian पर इसके लिए unattended-upgrades पैकेज का उपयोग होता है, जिसे /etc/apt/apt.conf.d/50unattended-upgrades में कॉन्फ़िगर किया जाता है। यहाँ आप उन ऑरिजिन्स (origins) की सूची देते हैं जिनसे अपडेट प्राप्त करने की अनुमति है। Ubuntu पर unattended upgrades सेट करना लेख में उस कॉन्फ़िगरेशन फ़ाइल और उससे जुड़े रीबूट के प्रश्न को विस्तार से समझाया गया है।

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

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

dnf-automatic-install.timer अपडेट को डाउनलोड और अप्लाई करता है। dnf-automatic-download.timer उन्हें केवल डाउनलोड करता है और रुक जाता है, ताकि इंस्टॉलेशन आप स्वयं कर सकें। dnf-automatic-notifyonly.timer केवल रिपोर्ट तैयार करता है। इनमें से प्रत्येक यूनिट /etc/dnf/automatic.conf में मौजूद apply_updates सेटिंग को ओवरराइड करती है, इसलिए कॉन्फ़िगरेशन फ़ाइल में क्या लिखा है, उससे अधिक महत्वपूर्ण यह है कि आप कौन सा टाइमर चुनते हैं। अपडेट इंस्टॉल करने से पुराना कोड चलाने वाली सर्विस अपने आप रीस्टार्ट नहीं होती है, इसलिए यह मान लेने से पहले कि सर्वर पैच हो गया है, यह जाँच लेना उचित है कि किन अपडेट्स के लिए रीबूट की आवश्यकता है और किनके लिए केवल सर्विस रीस्टार्ट की।

इसे केवल सुरक्षा सुधारों (security fixes) तक सीमित करने के लिए, /etc/dnf/automatic.conf में upgrade_type = security सेट करें। यह फ़िल्टर इस बात पर निर्भर करता है कि आपकी रिपॉजिटरी सुरक्षा संबंधी errata प्रकाशित करती है या नहीं, इसलिए पहले dnf updateinfo list security के साथ इसकी जाँच करें। यदि किसी सर्वर पर अपडेट लंबित हैं और परिणाम खाली आता है, तो इसका अर्थ है कि मेटाडेटा मौजूद नहीं है, और ऐसी स्थिति में security कुछ भी इंस्टॉल नहीं करेगा।

Fedora पर, dnf 5 ने इस यूनिट का नाम बदल दिया है। अब यह 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 में किया जाता है, और यह वही है जो system के dnf 5 पर जाने पर भी काम करती रहती है।

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

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

इसका सबसे स्पष्ट उदाहरण Docker है, जो प्रत्येक के लिए अलग रिपॉजिटरी कमांड प्रकाशित करता है। RHEL और इसके रीबिल्ड्स पर, 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

वेंडर एक ही है, काम एक ही है, लेकिन शब्द अलग हैं। dnf 5 ने config-manager को एक सब-कमांड आधारित टूल में बदल दिया है, इसलिए पुराना --add-repo फ्लैग स्वीकार नहीं किया जाता है और आपको रिपॉजिटरी के बजाय एक यूसेज एरर (usage error) मिलता है। एक और बदलाव जो आपको देखने को मिलेगा वह है रिपॉजिटरी को इनेबल करना: 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 स्टेटस के साथ एग्जिट होती है।

क्या 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 चलाकर इनेबल करते हैं।

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

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

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

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

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

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