Rocky اور Fedora پر apt کمانڈز کے dnf متبادل

مختصر جواب

apt سے dnf پر منتقل ہونا زیادہ تر اصطلاحات کی تبدیلی ہے۔ apt install nginx، dnf install nginx بن جاتا ہے۔ apt remove nginx، dnf remove nginx بن جاتا ہے۔ apt update کا کوئی براہ راست متبادل نہیں، کیونکہ cached copy پرانی ہونے پر dnf repository metadata خود تازہ کر لیتا ہے۔ ترجمے کا آسان حصہ ایک ہی اسکرین میں آ جاتا ہے۔ مفید حصہ ان چار operations پر مشتمل ہے جن کا کوئی براہ راست mapping نہیں ہوتا: repository شامل کرنا، transaction واپس کرنا، package group انسٹال کرنا، اور unattended updates چلانا۔

ذیل کے ہر command کو اپنے server پر چلانے کے لیے لکھا گیا ہے۔ 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 سے اخذ ہونے والی تمام distributions کا 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 کمانڈ

انسٹال، حذف، تلاش اور تفصیل دکھانا۔ دونوں طرف یہ تقریباً ایک ہی الفاظ استعمال کرتے ہیں۔

# 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 ان dependencies کو بھی حذف کرتا ہے جن کی کسی دوسری چیز کو ضرورت نہیں، جبکہ apt remove انہیں بعد کے apt autoremove کے لیے انسٹال رہنے دیتا ہے۔ اس لیے Rocky Linux پر ایک چھوٹی utility حذف کرنے سے ایک درجن libraries بھی حذف کرنے کی تجویز آ سکتی ہے۔ تصدیق سے پہلے فہرست پڑھیں۔

Metadata تازہ کریں، زیرِ التوا چیزیں دیکھیں، اور 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 استعمال کرتا ہے اور ایسے version کو بھی آسانی سے انسٹال کر دیتا ہے جو کئی ماہ پہلے archive سے خارج ہو چکا ہو۔ dnf ہر transaction سے پہلے اپنے cache کی عمر جانچتا ہے اور خود تازہ metadata download کر لیتا ہے، اس لیے sudo dnf makecache صرف اسی وقت download کو فوراً شروع کرنے کے لیے ہے، نہ کہ اگلی install کے دوران۔

apt پورے system upgrade کو دو حصوں میں تقسیم کرتا ہے، جبکہ dnf ایسا نہیں کرتا۔ apt upgrade کسی بھی installed package کو حذف کرنے سے انکار کرتا ہے، اس لیے جب کسی update کے لیے کوئی package حذف کرنا ضروری ہو تو یہ رک جاتا ہے۔ apt full-upgrade وہ version ہے جسے حذف کرنے کی اجازت ہے۔ dnf پر ایسی کوئی پابندی نہیں، اس لیے dnf upgrade، apt upgrade کے بجائے apt full-upgrade کے مساوی ہے۔ dnf update اسی command کا پرانا alias ہے اور اب بھی کام کرتا ہے۔

اگر آپ اسے script میں استعمال کرتے ہیں تو ایک تفصیل اہم ہے: dnf check-update updates زیرِ التوا ہونے پر status 100 اور کوئی update نہ ہونے پر 0 کے ساتھ exit کرتا ہے۔ apt list --upgradable دونوں صورتوں میں 0 کے ساتھ exit کرتا ہے، اس لیے scripts کو اس کے output کی parsing کرنا پڑتی ہے۔

دیکھیں کہ کیا installed ہے، اور معلوم کریں کہ کسی 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 صرف پہلے سے installed packages میں تلاش کرتے ہیں، اس لیے یہ جواب دیتے ہیں: "یہ file یہاں کس چیز نے رکھی؟" apt-file search اور dnf provides repositories میں تلاش کرتے ہیں، اس لیے یہ جواب دیتے ہیں: "یہ file حاصل کرنے کے لیے میں کون سا package انسٹال کروں؟" apt-file Ubuntu پر ایک الگ package ہے اور پہلی بار چلانے سے پہلے sudo apt-file update درکار ہوتا ہے۔ dnf provides کو کسی اضافی چیز کی ضرورت نہیں، اگرچہ پہلی بار یہ سست ہو سکتا ہے کیونکہ جواب دینے کے لیے dnf repository کی file lists download کرتا ہے۔

ایسے package کے اندر موجود files کی فہرست دیکھنے کے لیے جسے آپ نے ابھی انسٹال نہیں کیا، dnf repoquery -l nginx استعمال کریں۔ apt کی طرف اس کا مساوی apt-file list nginx ہے۔

خودکار حذف، 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 پر default طور پر انسٹال نہیں ہوتا، اس لیے نئے system پر ان میں سے پہلی سطر No such command: versionlock کے ساتھ ناکام ہو جاتی ہے۔ پہلے اسے sudo dnf install python3-dnf-plugin-versionlock کے ذریعے انسٹال کریں۔ apt کو apt-mark hold کے لیے کسی اضافی چیز کی ضرورت نہیں، کیونکہ hold، plugin کے بجائے dpkg state ہے۔

جہاں mapping ناکام ہوتی ہے: repository شامل کرنا

یہ وہ حصہ ہے جہاں Ubuntu administrators ایسے command کی تلاش شروع کر دیتے ہیں جو موجود ہی نہیں۔ dnf میں add-apt-repository نہیں ہے، اور personal package archives (PPAs) بھی نہیں ہیں۔ PPA، Launchpad کے ذریعے چلائی جانے والی service ہے، اور Launchpad، Ubuntu infrastructure کا حصہ ہے۔ RPM ecosystem میں ایسی کوئی infrastructure موجود نہیں جو PPA 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 کرنے کی ہدایت دیتے ہیں۔ Docker کی RHEL اور اس کے rebuilds کے لیے اپنی 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، dnf کا built-in حصہ نہیں بلکہ ایک plugin ہے۔ اسے چھوڑنے پر دوسری line No such command: config-manager کے ساتھ fail ہو جاتی ہے۔ آپ وہی .repo file `curl کے ذریعے manually /etc/yum.repos.d/` میں download کر سکتے ہیں۔ نتیجہ یکساں ہوگا۔ VPS پر Docker انسٹال کرنا اسی کام کا 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/ میں رکھتا ہے، اور key، .repo file کے اندر ایک URL ہوتی ہے۔ اس لیے پڑھنے کے لیے ایک file اور حذف کرنے کے لیے ایک file ہوتی ہے۔ نئے apt نے deb822 format کے ذریعے اسی layout کی طرف پیش رفت کی ہے، جہاں ہر repository کے لیے ایک .sources file ہوتی ہے۔ اگر آپ Ubuntu میں deb822 duplicate sources error دیکھ چکے ہیں، تو آپ اس مسئلے کے apt والے حصے سے پہلے ہی واقف ہیں۔

EPEL وہ archive ہے جسے زیادہ تر guides پہلے سے فعال فرض کرتی ہیں

Extra Packages for Enterprise Linux (EPEL) ایک Fedora project ہے جو RHEL اور اس کی rebuilds کے لیے Fedora packages بناتا ہے۔ یہ universal PPA کے قریب ترین چیز ہے، اور بہت بڑی تعداد میں tutorials یہ فرض کرتے ہیں کہ یہ پہلے سے enabled ہے۔ اگر dnf install کسی ایسے package کے لیے No match for argument کا جواب دیتا ہے جو project کی اپنی website پر موجود ہے، تو EPEL سب سے پہلے check کرنے والی چیز ہے۔

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 اس repository میں موجود کسی component پر depend کرتے ہیں۔ اس لیے CRB کے بغیر EPEL کو enable کرنا اسی وقت failure ظاہر نہیں کرتا۔ Failure بعد میں install کے وقت ہوتا ہے، جب کسی ایسے package کی unresolved dependencies سامنے آتی ہیں جس کا آپ نے کبھی نام نہیں سنا۔ پہلے CRB کو enable کریں، تو اس قسم کی error ختم ہو جاتی ہے۔

خود RHEL پر CRB آپ کی subscription کے ذریعے دستیاب ہوتا ہے، config-manager کے ذریعے نہیں۔ اس لیے اس مرحلے کے لیے Red Hat کی اپنی EPEL instructions پر عمل کریں۔ Fedora کو ان میں سے کسی چیز کی ضرورت نہیں، کیونکہ اس کا main repository پہلے ہی وہ packages فراہم کرتا ہے جنہیں EPEL backport کرتا ہے۔ EPEL policy کے مطابق وہ کسی ایسے package کو کبھی replace نہیں کرتا جسے RHEL ship کرتا ہے۔ اس لیے 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 transactions کی نمبر وار فہرست دکھاتا ہے، ساتھ ہی وہ command line بھی دکھاتا ہے جس سے ہر transaction شروع ہوا تھا۔ undo مخالف transaction تیار کرتا ہے: اس transaction کے ذریعے install کیے گئے packages remove ہو جاتے ہیں، اور upgrade کیے گئے packages اس version پر واپس آ جاتے ہیں جو پہلے موجود تھا۔ apt استعمال کرنے والے switch کرنے کے بعد اسی feature کو سب سے زیادہ محسوس کرتے ہیں۔

اس کی حقیقی حدود ہیں، اور اس پر انحصار کرنے سے پہلے انہیں جاننا ضروری ہے۔ undo صرف اسی package version کو دوبارہ install کر سکتا ہے جو اب بھی کسی enabled repository میں موجود ہو۔ اس لیے mirror سے پرانا build ہٹا دیے جانے کے بعد undo، not-found error کے ساتھ ناکام ہو جاتا ہے۔ Rollback package database تک محدود رہتا ہے۔ Upgrade نے جو config file دوبارہ لکھ دی ہو، وہ اسی طرح بدلی ہوئی رہتی ہے، اور service کے پہلی بار start ہونے پر جو database schema migrate ہو چکا ہو، وہ migrated ہی رہتا ہے۔ dnf files واپس رکھتا ہے۔ یہ آپ کا data واپس نہیں کرتا۔

apt میں اس کے مساوی کوئی feature نہیں ہے۔ /var/log/apt/history.log بالکل درست ریکارڈ رکھتا ہے کہ کیا ہوا، جس میں command line بھی شامل ہے، لیکن log پڑھنا اسے undo نہیں کرتا۔ apt کے ذریعے recovery دستی طور پر کرنی پڑتی ہے: پہلے apt list -a nginx چلائیں تاکہ معلوم ہو سکے کہ archive میں اب بھی کون سے versions موجود ہیں، پھر کسی version کو pin کرنے کے لیے sudo apt install nginx=<exact version string> چلائیں، اور sudo apt-mark hold nginx شامل کریں تاکہ اگلا upgrade آپ کی اصلاح ختم نہ کر دے۔

Package groups کا کوئی apt متبادل نہیں

dnf ایک ہی command میں packages کے نامزد set کو 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۔ عملی فرق packages ہٹاتے وقت سامنے آتا ہے: metapackage ہٹانے سے اس کی dependencies install رہتی ہیں، جب تک آپ apt autoremove نہ چلائیں، جبکہ dnf group remove اسی transaction میں group کے packages بھی ہٹا دیتا ہے۔

unattended-upgrades اور dnf-automatic

دونوں package families اس مقصد کے لیے updates install کرنے کا طریقہ فراہم کرتی ہیں کہ کوئی user logged in نہ ہو۔ ان دونوں میں مقصد کے علاوہ کوئی چیز مشترک نہیں ہے۔

Ubuntu اور Debian میں package unattended-upgrades ہے، جسے /etc/apt/apt.conf.d/50unattended-upgrades میں configure کیا جاتا ہے۔ اس file میں وہ origins درج کیے جاتے ہیں جہاں سے updates حاصل کرنے کی اجازت ہو۔ Ubuntu پر unattended upgrades ترتیب دینا میں اس config file اور اس کے ساتھ وابستہ reboot کے سوال کی وضاحت کی گئی ہے۔

Rocky Linux، AlmaLinux اور Fedora میں package dnf-automatic ہے۔ آپ جو systemd timer enable کرتے ہیں، وہ اس کا behaviour متعین کرتا ہے۔

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 کرتا ہے اور رک جاتا ہے، تاکہ installation آپ خود کریں۔ dnf-automatic-notifyonly.timer صرف report کرتا ہے۔ ان میں سے ہر unit /etc/dnf/automatic.conf میں موجود apply_updates setting کو override کرتا ہے، اس لیے آپ کا منتخب کردہ timer config file میں موجود setting سے زیادہ اہم ہے۔

اسے صرف security fixes تک محدود کرنے کے لیے /etc/dnf/automatic.conf میں upgrade_type = security set کریں۔ یہ filter اس بات پر منحصر ہے کہ آپ کی repositories security errata publish کرتی ہوں۔ اس لیے پہلے dnf updateinfo list security سے جانچ کریں۔ ایسے system پر جس میں updates pending ہوں، empty 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 ایک symbolic link ہے جو dnf کی طرف اشارہ کرتا ہے۔ اپنے سسٹم پر اسے چیک کریں:

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

پرانے tutorials میں yum کا syntax اب بھی نظر آتا ہے، کیونکہ اس کا بیشتر حصہ براہ راست کام کرتا رہتا ہے۔ yum install، yum remove اور yum update سب کام کرتے ہیں۔ ایک عادت ترک کرنا بہتر ہے: dnf 4 systems میں yum-config-manager اب بھی اپنی الگ binary کے طور پر موجود ہے، لیکن dnf config-manager وہ syntax ہے جسے موجودہ documentation استعمال کرتی ہے، اور جب سسٹم dnf 5 پر منتقل ہو تو یہی syntax کام کرتا رہتا ہے۔

dnf 4 اور dnf 5: command نقل کرنے سے پہلے جانچ کریں

dnf 5 دوبارہ لکھا گیا ورژن ہے، اور اس میں کئی commands کے ہجے تبدیل کیے گئے ہیں۔ Fedora 41 اور بعد کے ورژنز میں یہ dnf کے طور پر شامل ہے۔ enterprise rebuilds نے اس تبدیلی کو اپنانے میں زیادہ وقت لیا ہے، اس لیے distribution کے نام سے اندازہ نہ لگائیں۔ اپنے سرور پر dnf --version چلائیں اور پہلی لائن پڑھیں، کیونکہ یہی version number طے کرتا ہے کہ ذیل میں دی گئی کون سی syntax آپ کو درکار ہے۔

اس کی سب سے واضح مثال Docker ہے، جو دونوں versions کے لیے الگ 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-based tool میں تبدیل کر دیا، اس لیے پرانا --add-repo flag قبول نہیں ہوتا اور repository بنانے کے بجائے usage error ظاہر ہوتی ہے۔ ایک اور فرق repository کو enable کرنے کے command میں نظر آئے گا: 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 تیزی سے نئے releases جاری کرتا ہے، اور ہر release کے دستیاب ہونے کے تقریباً تیرہ ماہ بعد اسے updates ملنا بند ہو جاتے ہیں۔ یہ workstation کے لیے مناسب ہے، لیکن ایسے server کے لیے مشکل ہے جسے آپ دوبارہ build نہیں کرنا چاہتے۔ Rocky Linux اور AlmaLinux، RHEL کے releases اور package policies کی پیروی کرتے ہیں۔ اس لیے آپ کو دس سال کی support window ملتی ہے، جبکہ package versions کو دانستہ طور پر زیادہ تبدیل نہیں کیا جاتا۔ Ubuntu دونوں طرزیں فراہم کرتا ہے، اور server پر Ubuntu LTS اور interim releases کے درمیان فرق apt کی دنیا کے اندر یہی فیصلہ ہے۔

August 2026 تک، یہ سب عام VPS images ہیں۔ اپنی مطلوبہ support window منتخب کریں، پھر اوپر دیے گئے دس commands سیکھیں۔

FAQ

apt update کے مساوی dnf کمانڈ کیا ہے؟

آپ کو کوئی کمانڈ چلانے کی ضرورت نہیں۔ ہر transaction سے پہلے dnf جانچتا ہے کہ اس کا cached metadata کتنا پرانا ہے، اور metadata کی مدت ختم ہو چکی ہو تو تازہ copy download کر لیتا ہے۔ اس لیے dnf install ایسے سرور پر بھی موجودہ packages دیکھتا ہے جسے آپ نے ایک ماہ سے استعمال نہیں کیا۔ sudo dnf makecache موجود ہے اور یہ download لازماً شروع کر دیتا ہے، لیکن اس کا اصل فائدہ یہ ہے کہ تاخیر کو اگلی installation کے بجائے آپ کے منتخب کردہ وقت پر منتقل کر دیتا ہے۔ سوال "میرے لیے کیا منتظر ہے؟" کا جواب دینے والی کمانڈ 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 استعمال کیا جاتا ہے، جسے 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> چلائیں۔ اگر پرانا package version کسی بھی enabled repository میں موجود نہ ہو تو undo ناکام ہو جاتا ہے، کیونکہ dnf کے پاس reinstall کرنے کے لیے کچھ نہیں ہوتا۔ یہ صرف package changes کو واپس کرتا ہے۔ Upgrade کے دوران دوبارہ لکھی گئی configuration file، یا service کے پہلی بار start ہونے پر migrate کیا گیا database، اپنی موجودہ حالت میں رہتا ہے۔ apt میں اس کے مساوی کوئی کمانڈ نہیں؛ صرف /var/log/apt/history.log میں موجود record دستیاب ہوتا ہے۔

کیا yum اب بھی Rocky Linux اور AlmaLinux پر کام کرتا ہے؟

یہ اس لیے کام کرتا ہے کہ /usr/bin/yum، dnf کی symbolic link ہے۔ اپنے server پر 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 حذف کیوں کرنا چاہتا ہے؟

کیونکہ dnf اسی transaction کے دوران ایسی dependencies بھی حذف کر دیتا ہے جن کی کسی دوسری چیز کو ضرورت نہیں رہتی، جبکہ apt remove انہیں اس وقت تک installed رکھتا ہے جب تک آپ الگ سے apt autoremove نہ چلائیں۔ اسی لیے Ubuntu پر چھوٹی نظر آنے والی removal، Rocky Linux پر لمبی فہرست دکھا سکتی ہے۔ یہ فہرست عموماً درست ہوتی ہے، لیکن تصدیق سے پہلے اسے پڑھیں۔ اگر فہرست میں موجود کوئی package آپ رکھنا چاہتے ہیں تو اسے پہلے explicitly install کریں، تاکہ dnf اسے اپنے طور پر مطلوب package کے طور پر record کر لے۔