apt کمانڈز کا dnf متبادل: Rocky Linux اور Fedora گائیڈ

مختصر جواب

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

نیچے دی گئی ہر کمانڈ آپ کے اپنے سرور پر چلانے کے لیے لکھی گئی ہے۔ y کا جواب دینے سے پہلے dnf کی طرف سے پرنٹ کردہ transaction summary کو ضرور پڑھیں، خاص طور پر ہٹانے (removals) کے عمل کے دوران۔

کون سی ڈسٹروز dnf استعمال کرتی ہیں اور کون سی apt

dnf پیکیج مینیجر Fedora، Red Hat Enterprise Linux (RHEL)، اور RHEL کے rebuilds یعنی Rocky Linux، AlmaLinux اور CentOS Stream پر استعمال ہوتا ہے۔ apt پیکیج مینیجر Debian اور اس سے ماخوذ تمام سسٹمز پر استعمال ہوتا ہے، جس کا VPS پر مطلب تقریباً ہمیشہ Ubuntu ہوتا ہے۔ اس کا کوئی تیسرا جواب نہیں ہے۔ اگر آپ کے پرووائیڈر کی امیج لسٹ Rocky Linux یا AlmaLinux پیش کرتی ہے، تو آپ dnf استعمال کر رہے ہوں گے۔ اگر وہ Ubuntu پیش کرتی ہے، تو آپ apt استعمال کر رہے ہوں گے۔ اس تقسیم کے ایک طرف چار نام کیوں ہیں جبکہ وہ بنیادی طور پر ایک ہی سسٹم ہے، یہ ایک ایسی کہانی ہے جسے آپ کے انتخاب سے پہلے جاننا ضروری ہے، اور Red Hat Linux کیسے Fedora، RHEL، CentOS، Rocky اور AlmaLinux بنا اس بات کی وضاحت کرتا ہے کہ ہر ایک کہاں سے آیا ہے۔

پیکیج فارمیٹ ٹول کے مطابق ہوتا ہے۔ dnf .rpm فائلیں انسٹال کرتا ہے اور اس کا ڈیٹا بیس rpm ہے۔ apt .deb فائلیں انسٹال کرتا ہے اور اس کا ڈیٹا بیس dpkg ہے۔ یہی وجہ ہے کہ بہت سے وینڈر انسٹال پیجز پر ہر فیملی کے لیے ایک الگ ٹیب ہوتا ہے، اور یہی وجہ ہے کہ کسی پروجیکٹ کے ریلیز پیج سے ڈاؤن لوڈ کردہ .deb، Rocky Linux پر بے کار ہے۔

آپ جس فیملی کا بھی انتخاب کریں، پہلی لاگ ان پر کام ایک جیسا ہی ہوتا ہے۔ نئے VPS پر ابتدائی دس منٹ دونوں پر لاگو ہوتے ہیں۔ صرف انسٹال کرنے والی کمانڈ تبدیل ہوتی ہے۔

ہر 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 پر ایک چھوٹی یوٹیلیٹی کو ہٹانے سے درجنوں لائبریریاں ہٹنے کی تجویز آ سکتی ہے۔ تصدیق کرنے سے پہلے فہرست کو غور سے پڑھیں۔

میٹا ڈیٹا ریفریش کریں، چیک کریں کہ کیا اپ ڈیٹ انتظار میں ہے، اور اپ گریڈ کریں۔

# 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 update کا استعمال apt کی طرف لازمی ہے، کیونکہ apt ڈسک پر موجود پرانے میٹا ڈیٹا کو استعمال کرتا ہے اور خوشی سے وہ ورژن انسٹال کر دیتا ہے جو مہینوں پہلے آرکائیو سے ہٹ چکا ہو۔ dnf ہر ٹرانزیکشن سے پہلے اپنے کیشے کی عمر چیک کرتا ہے اور خود بخود تازہ میٹا ڈیٹا ڈاؤن لوڈ کر لیتا ہے، اس لیے sudo dnf makecache صرف اس وقت استعمال ہوتا ہے جب آپ اگلی انسٹالیشن کا انتظار کیے بغیر ابھی ڈاؤن لوڈ کرنا چاہتے ہوں۔

apt پورے سسٹم کے اپ گریڈ کو دو حصوں میں تقسیم کرتا ہے، جبکہ dnf ایسا نہیں کرتا۔ apt upgrade کسی بھی انسٹال شدہ پیکیج کو ہٹانے سے انکار کرتا ہے، اس لیے جب کسی اپ ڈیٹ کے لیے کسی پیکیج کو ہٹانا ضروری ہو تو یہ رک جاتا ہے۔ apt full-upgrade وہ ورژن ہے جسے ہٹانے کی اجازت ہے۔ dnf میں ایسی کوئی پابندی نہیں ہے، جس کا مطلب ہے کہ dnf upgrade دراصل apt full-upgrade کا متبادل ہے، نہ کہ apt upgrade کا۔ dnf update اسی کمانڈ کا ایک پرانا عرفی نام (alias) ہے اور اب بھی کام کرتا ہے۔

اگر آپ اس عمل کو اسکرپٹ کر رہے ہیں تو ایک تفصیل اہم ہے: dnf check-update اپ ڈیٹس موجود ہونے پر status 100 اور نہ ہونے پر 0 کے ساتھ ایگزٹ ہوتا ہے۔ apt list --upgradable دونوں صورتوں میں 0 کے ساتھ ایگزٹ ہوتا ہے، اس لیے اسکرپٹس کو اس کی آؤٹ پٹ کو پارس (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 ریپوزٹریز میں تلاش کرتے ہیں، اس لیے وہ اس سوال کا جواب دیتے ہیں کہ "اس فائل کو حاصل کرنے کے لیے مجھے کیا انسٹال کرنا چاہیے"۔ apt-file Ubuntu پر ایک الگ پیکیج ہے اور اسے پہلی بار چلانے سے پہلے sudo apt-file update کی ضرورت ہوتی ہے۔ dnf provides کو کسی اضافی چیز کی ضرورت نہیں ہوتی، حالانکہ پہلی بار چلنے میں یہ سست ہو سکتا ہے کیونکہ dnf جواب دینے کے لیے ریپوزٹری فائل لسٹس ڈاؤن لوڈ کرتا ہے۔

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

آٹو ریموو، کیشے صاف کرنا، ورژن کو ہولڈ کرنا۔

# 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 اسٹیٹ ہے نہ کہ پلگ ان۔

جہاں میپنگ ٹوٹتی ہے: ریپوزٹری شامل کرنا

یہ وہ حصہ ہے جو Ubuntu کے ایڈمنز کو ایسے کمانڈ کی تلاش میں لگا دیتا ہے جو وجود ہی نہیں رکھتی۔ dnf میں کوئی add-apt-repository نہیں ہوتا، اور نہ ہی کوئی پرسنل پیکیج آرکائیوز (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 دونوں پر کام کرتی ہے۔

زیادہ تر وینڈرز وہ فائل شائع کرتے ہیں اور آپ کو اسے حاصل کرنے کا کہتے ہیں۔ 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 پیکیجز تیار کرتا ہے۔ یہ اس دنیا میں universal PPA کے سب سے قریب ہے، اور بہت بڑی تعداد میں ٹیوٹوریلز یہ فرض کر لیتے ہیں کہ یہ پہلے سے فعال ہے۔ اگر 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 ہے، یہ لائبریریوں کا ایک ریپوزٹری ہے جو ڈسٹری بیوشن کے ساتھ آتی ہے لیکن بائی ڈیفالٹ فعال نہیں ہوتی۔ زیادہ تر EPEL پیکیجز اس میں موجود کسی چیز پر انحصار کرتے ہیں، اس لیے CRB کے بغیر EPEL کو فعال کرنا اس لمحے تو ناکام نہیں ہوتا۔ یہ بعد میں، انسٹالیشن کے وقت، کسی ایسے پیکیج پر unresolved dependencies کے ساتھ ناکام ہوتا ہے جس کا آپ نے کبھی نام نہیں سنا ہوگا۔ پہلے CRB کو فعال کریں اور اس قسم کی غلطی ختم ہو جائے گی۔

خود RHEL پر، CRB آپ کی سبسکرپشن کے ذریعے آتا ہے نہ کہ config-manager کے ذریعے، لہذا اس مرحلے کے لیے Red Hat کی اپنی EPEL ہدایات پر عمل کریں۔ Fedora کو اس کی ضرورت نہیں ہے، کیونکہ اس کی مرکزی ریپوزٹری میں پہلے سے ہی وہ سب کچھ موجود ہوتا ہے جو EPEL بیک پورٹ کرتا ہے۔ EPEL کی پالیسی یہ ہے کہ وہ کبھی بھی RHEL کے فراہم کردہ پیکیج کو تبدیل نہیں کرتا، لہذا ریپوزٹری شامل کرنے سے آپ کے سرور پر پہلے سے انسٹال شدہ کسی بھی چیز میں کوئی تبدیلی نہیں آتی۔

dnf history undo، وہ کام جو apt نہیں کر سکتا

dnf ہر ٹرانزیکشن کا ریکارڈ رکھتا ہے، اور یہ اس کا الٹ (reverse) بھی تیار کر سکتا ہے۔

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

dnf history ٹرانزیکشنز کی ایک نمبر والی فہرست پرنٹ کرتا ہے جس میں وہ کمانڈ لائن بھی شامل ہوتی ہے جس نے ہر ایک کو شروع کیا۔ undo اس کے برعکس ٹرانزیکشن بناتا ہے: جن پیکجز کو اس ٹرانزیکشن نے انسٹال کیا تھا وہ ہٹا دیے جاتے ہیں، اور جن پیکجز کو اپ گریڈ کیا گیا تھا وہ واپس پرانے ورژن پر چلے جاتے ہیں۔ یہ وہ فیچر ہے جسے apt استعمال کرنے والے dnf پر منتقل ہونے کے بعد سب سے زیادہ یاد کرتے ہیں۔

اس کی کچھ حقیقی حدود ہیں، اور ان پر انحصار کرنے سے پہلے انہیں جاننا ضروری ہے۔ undo صرف اسی پیکج ورژن کو دوبارہ انسٹال کر سکتا ہے جو کسی فعال ریپوزٹری میں موجود ہو، لہذا جب پرانا بلڈ مرر سے ہٹا دیا جاتا ہے تو undo ایک not-found ایرر کے ساتھ ناکام ہو جاتا ہے۔ رول بیک (rollback) بھی صرف پیکج ڈیٹا بیس تک محدود رہتا ہے۔ اپ گریڈ کے دوران دوبارہ لکھی گئی کنفیگریشن فائل ویسی ہی رہتی ہے، اور ڈیٹا بیس اسکیما جسے سروس نے پہلی بار شروع ہونے پر مائیگریٹ کیا تھا، وہ بھی مائیگریٹ شدہ ہی رہتا ہے۔ dnf فائلیں واپس اپنی جگہ پر رکھ دیتا ہے، لیکن یہ آپ کا ڈیٹا واپس نہیں لاتا۔

apt میں اس کا کوئی متبادل نہیں ہے۔ /var/log/apt/history.log صرف یہ ریکارڈ کرتا ہے کہ کیا ہوا، بشمول کمانڈ لائن، لیکن لاگ پڑھنا اسے undo کرنا نہیں ہے۔ apt کی طرف سے ریکوری دستی (manual) ہے: یہ دیکھنے کے لیے کہ آرکائیو میں کون سے ورژنز موجود ہیں apt list -a nginx چلائیں، پھر کسی ایک کو پن (pin) کرنے کے لیے sudo apt install nginx=<exact version string> استعمال کریں، اور sudo apt-mark hold nginx شامل کریں تاکہ اگلی اپ گریڈ آپ کی درستگی کو ختم نہ کر دے۔

Package groups کا کوئی 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

یہ دونوں خاندان بغیر کسی صارف کے لاگ ان ہوئے اپ ڈیٹس انسٹال کرنے کا طریقہ فراہم کرتے ہیں۔ ان ٹولز کا مقصد ایک ہی ہے لیکن ان میں کوئی اور مماثلت نہیں ہے۔

Ubuntu اور Debian پر پیکیج unattended-upgrades ہے، جسے /etc/apt/apt.conf.d/50unattended-upgrades میں کنفیگر کیا جاتا ہے، جہاں آپ ان ذرائع (origins) کی فہرست دیتے ہیں جن سے اپ ڈیٹس حاصل کرنے کی اجازت ہے۔ Ubuntu پر unattended upgrades کی ترتیب اس کنفیگریشن فائل اور اس کے ساتھ آنے والے ریبوٹ کے سوال کا احاطہ کرتی ہے۔

Rocky Linux، AlmaLinux اور Fedora پر پیکیج dnf-automatic ہے، اور آپ جس systemd ٹائمر کو فعال کرتے ہیں وہ اس کے رویے کا تعین کرتا ہے۔

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 سیٹنگ کو اوور رائڈ (override) کرتا ہے، لہذا آپ جو ٹائمر منتخب کرتے ہیں وہ کنفیگریشن فائل میں لکھی بات سے زیادہ اہمیت رکھتا ہے۔ اپ ڈیٹ انسٹال کرنے سے وہ سروس خود بخود ری سٹارٹ نہیں ہوتی جو پرانا کوڈ چلا رہی ہو، اس لیے یہ چیک کرنا ضروری ہے کہ کون سی اپ ڈیٹس کو ریبوٹ کی ضرورت ہے اور کن کے لیے صرف سروس ری سٹارٹ کافی ہے، اس سے پہلے کہ آپ یہ فرض کر لیں کہ سسٹم پیچ ہو چکا ہے۔

اسے صرف سیکیورٹی فکسز تک محدود کرنے کے لیے، /etc/dnf/automatic.conf میں upgrade_type = security سیٹ کریں۔ یہ فلٹر اس بات پر منحصر ہے کہ آپ کی ریپوزٹریز سیکیورٹی errata شائع کرتی ہیں یا نہیں، لہذا پہلے dnf updateinfo list security کے ساتھ چیک کریں۔ اگر کسی ایسے سسٹم پر، جس میں اپ ڈیٹس باقی ہوں، نتیجہ خالی آئے تو اس کا مطلب ہے کہ میٹا ڈیٹا موجود نہیں ہے، اور ایسی صورت میں security کچھ بھی انسٹال نہیں کرے گا۔

Fedora پر، dnf 5 نے یونٹ کا نام تبدیل کر دیا ہے۔ یہ dnf5-automatic.timer ہے، اور یہ اسی /etc/dnf/automatic.conf کو پڑھتا ہے۔

کیا yum اب بھی ایک حقیقی کمانڈ ہے؟

جی ہاں، اور یہ بذات خود کچھ نہیں کرتی۔ Rocky Linux، AlmaLinux اور CentOS Stream پر، /usr/bin/yum ایک symbolic link ہے جو dnf کی طرف اشارہ کرتی ہے۔ اپنی سسٹم پر چیک کریں:

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

پرانی yum syntax ٹیوٹوریلز میں اس لیے نظر آتی ہے کیونکہ اس کا زیادہ تر حصہ اب بھی براہ راست کام کرتا ہے۔ yum install، yum remove اور yum update سب کام کرتے ہیں۔ ایک عادت ترک کر دینا بہتر ہے: yum-config-manager اب بھی dnf 4 سسٹمز پر اپنی الگ بائنری کے طور پر موجود ہے، لیکن dnf config-manager وہ ہجے (spelling) ہے جو موجودہ دستاویزات استعمال کرتی ہیں، اور یہی وہ کمانڈ ہے جو سسٹم کے dnf 5 پر منتقل ہونے کے بعد بھی کام کرتی رہے گی۔

dnf 4 اور dnf 5: کمانڈ کاپی کرنے سے پہلے چیک کریں

dnf 5 ایک مکمل rewrite ہے، اور اس نے کئی کمانڈز کے ہجے تبدیل کر دیے ہیں۔ Fedora 41 اور اس کے بعد کے ورژنز اسے dnf کے طور پر ریلیز کرتے ہیں۔ انٹرپرائز ری بلڈز (enterprise rebuilds) نے اس تبدیلی کو اپنانے میں سستی دکھائی ہے، لہذا صرف ڈسٹری بیوشن کے نام سے اندازہ نہ لگائیں۔ اپنے سرور پر dnf --version چلائیں اور پہلی لائن پڑھیں، کیونکہ وہی نمبر یہ طے کرتا ہے کہ آپ کو نیچے دی گئی کون سی syntax استعمال کرنی ہے۔

اس کی واضح ترین مثال Docker ہے، جو ہر ایک کے لیے مختلف repository کمانڈ شائع کرتا ہے۔ 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 کو ایک subcommand پر مبنی ٹول میں تبدیل کر دیا ہے، اس لیے پرانا --add-repo فلیگ قبول نہیں کیا جاتا اور آپ کو repository کے بجائے usage error ملتا ہے۔ ایک اور تبدیلی جو آپ دیکھیں گے وہ repository کو enable کرنا ہے: dnf 4 پر dnf config-manager --set-enabled crb، dnf 5 پر dnf config-manager setopt crb.enabled=1 بن جاتا ہے۔

وہ انتخاب جو درحقیقت اہمیت رکھتا ہے

صرف package manager کی بنیاد پر سرور ڈسٹری بیوشن کا انتخاب کرنا غلط معیار ہے۔ dnf اور apt ایک ہی کام کرتے ہیں، اور ان کی اصطلاحات سیکھنے میں صرف ایک دوپہر لگتی ہے۔ جو چیز آپ کے سال بھر کے تجربے کو متاثر کرتی ہے وہ repository کے پیچھے کارفرما release model ہے۔ Fedora تیزی سے اپ ڈیٹ ہوتا ہے اور کوئی بھی release جاری ہونے کے تقریباً 13 ماہ بعد اپ ڈیٹس حاصل کرنا بند کر دیتی ہے، جو کہ ورک سٹیشن کے لیے تو ٹھیک ہے لیکن ایسے سرور کے لیے تکلیف دہ ہے جسے آپ بار بار rebuild نہیں کرنا چاہتے۔ Rocky Linux اور AlmaLinux، RHEL کی پیروی کرتے ہیں، لہذا آپ کو 10 سالہ سپورٹ ونڈو اور ایسے package ورژنز ملتے ہیں جو جان بوجھ کر تبدیل نہیں ہوتے۔ Ubuntu دونوں طرح کے آپشنز پیش کرتا ہے، اور سرور پر Ubuntu LTS اور interim releases کے درمیان فرق وہی فیصلہ ہے جو apt کی دنیا میں کیا جاتا ہے۔

اگست 2026 تک، یہ تمام عام VPS امیجز ہیں۔ اپنی مطلوبہ سپورٹ ونڈو کا انتخاب کریں، اور پھر اوپر دیے گئے 10 کمانڈز سیکھ لیں۔

FAQ

apt update کا dnf متبادل کیا ہے؟

آپ کو کوئی کمانڈ چلانے کی ضرورت نہیں ہے۔ dnf ہر ٹرانزیکشن سے پہلے چیک کرتا ہے کہ اس کا cached metadata کتنا پرانا ہے، اور میعاد ختم ہونے پر تازہ کاپی ڈاؤن لوڈ کر لیتا ہے۔ لہذا، ایک ایسے سرور پر dnf install چلانا جسے آپ نے ایک ماہ سے نہیں چھیڑا، تب بھی موجودہ پیکجز دکھائے گا۔ sudo dnf makecache موجود ہے اور یہ ڈاؤن لوڈ کو زبردستی کر دیتا ہے، لیکن اس کا اصل مقصد تاخیر کو اس وقت منتقل کرنا ہے جو آپ منتخب کریں، نہ کہ آپ کی اگلی انسٹالیشن کے دوران۔ وہ کمانڈ جو اس سوال کا جواب دیتی ہے کہ "میرے لیے کیا انتظار کر رہا ہے" وہ dnf check-update ہے، جو apt list --upgradable پر میپ ہوتی ہے اور اپ ڈیٹس دستیاب ہونے پر 100 اسٹیٹس کے ساتھ ایگزٹ ہوتی ہے۔

کیا Rocky Linux یا Fedora پر PPA کا کوئی متبادل ہے؟

نہیں۔ Personal package archives ایک Launchpad سروس ہے اور Launchpad اوبنٹو کا انفراسٹرکچر ہے، اس لیے 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 کو واپس کر سکتا ہوں جس نے میرے سرور کو خراب کر دیا؟

ہاں، حدود کے اندر۔ ٹرانزیکشن نمبر تلاش کرنے کے لیے sudo dnf history چلائیں، یہ دیکھنے کے لیے کہ اس نے بالکل کیا تبدیل کیا sudo dnf history info <id> چلائیں، اور پھر sudo dnf history undo <id> چلائیں۔ اگر پرانا پیکج ورژن کسی بھی فعال ریپوزٹری میں موجود نہ ہو تو انڈو (undo) ناکام ہو جاتا ہے، کیونکہ dnf کے پاس دوبارہ انسٹال کرنے کے لیے کچھ نہیں ہوتا۔ یہ صرف پیکج کی تبدیلیوں کو ریورس کرتا ہے۔ اپ گریڈ کے ذریعے دوبارہ لکھی گئی کنفیگریشن فائل، یا پہلی بار اسٹارٹ ہونے پر کسی سروس کے ذریعے مائیگریٹ کیا گیا ڈیٹا بیس، اپنی جگہ پر ویسا ہی رہتا ہے۔ apt میں اس طرح کی کوئی کمانڈ نہیں ہے، صرف /var/log/apt/history.log میں ریکارڈ موجود ہوتا ہے۔

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

یہ کام کرتا ہے کیونکہ /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 نہ چلائیں۔ لہذا، اوبنٹو پر جو ہٹانا چھوٹا لگتا ہے وہ Rocky Linux پر ایک لمبی فہرست دکھا سکتا ہے۔ فہرست عام طور پر درست ہوتی ہے، لیکن تصدیق کرنے سے پہلے اسے پڑھ لیں۔ اگر اس میں کوئی ایسا پیکج ہے جسے آپ رکھنا چاہتے ہیں، تو اسے پہلے واضح طور پر انسٹال کریں تاکہ dnf اسے اپنی مرضی کے مطابق ریکارڈ کر لے۔