معادل دستورهای apt در Rocky و Fedora با dnf

پاسخ کوتاه

مهاجرت از apt به dnf بیشتر تغییر واژگان است. apt install nginx به dnf install nginx تبدیل می‌شود. apt remove nginx به dnf remove nginx تبدیل می‌شود. apt update معادل مستقیمی ندارد، زیرا dnf وقتی نسخهٔ cached قدیمی شود، metadata مخزن‌ها را به‌طور خودکار تازه می‌کند. بخش سادهٔ این تبدیل در یک صفحه خلاصه می‌شود. بخش مفید آن چهار عملیاتی است که اصلاً نگاشت مستقیمی ندارند: افزودن مخزن، برگرداندن یک transaction، نصب یک package group و اجرای updateهای بدون نیاز به دخالت کاربر.

هر فرمان زیر برای اجرا روی سرور خودتان نوشته شده است. پیش از پاسخ به y، خلاصهٔ transaction را که dnf نمایش می‌دهد بخوانید؛ این کار به‌ویژه هنگام حذف بسته‌ها اهمیت دارد.

کدام توزیع‌ها از dnf استفاده می‌کنند و کدام‌یک از apt

dnf مدیر بسته در Fedora، Red Hat Enterprise Linux (RHEL) و بازسازی‌های RHEL، یعنی Rocky Linux، AlmaLinux و CentOS Stream است. apt مدیر بسته در Debian و تمام توزیع‌های مشتق‌شده از Debian است که در یک VPS تقریباً همیشه به Ubuntu اشاره دارد. پاسخ سومی وجود ندارد. اگر فهرست image ارائه‌دهنده شما 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 وابستگی‌هایی را هم که هیچ بسته دیگری به آن‌ها نیاز ندارد حذف می‌کند، اما apt remove آن‌ها را برای یک apt autoremove بعدی نصب‌شده نگه می‌دارد. بنابراین حذف یک ابزار کوچک در Rocky Linux ممکن است حذف دوازده کتابخانه را نیز پیشنهاد کند. پیش از تأیید، فهرست را بخوانید.

تازه‌سازی 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 update در سمت apt الزامی است، زیرا apt از metadata موجود روی دیسک استفاده می‌کند و ممکن است با خیال راحت نسخه‌ای را نصب کند که ماه‌ها پیش از archive خارج شده است. dnf پیش از هر transaction قدیمی‌بودن cache خود را بررسی می‌کند و metadata تازه را به‌صورت خودکار دانلود می‌کند؛ بنابراین sudo dnf makecache فقط برای اجبار به انجام این دانلود در همین لحظه است، نه هنگام نصب بعدی.

apt ارتقای کل سیستم را به دو بخش تقسیم می‌کند، اما dnf چنین کاری نمی‌کند. apt upgrade از حذف هر بسته نصب‌شده خودداری می‌کند؛ بنابراین هرگاه یک update به حذف بسته‌ای نیاز داشته باشد، متوقف می‌شود. apt full-upgrade نسخه‌ای است که اجازه حذف دارد. dnf چنین محدودیتی ندارد؛ بنابراین dnf upgrade معادل apt full-upgrade است، نه apt upgrade. dnf update نام مستعار قدیمی‌تر همین دستور است و همچنان کار می‌کند.

اگر این دستورها را در script استفاده می‌کنید، یک نکته مهم است: dnf check-update وقتی update در انتظار وجود دارد با status برابر 100 و وقتی موردی وجود ندارد با status برابر 0 خارج می‌شود. apt list --upgradable در هر دو حالت با status برابر 0 خارج می‌شود؛ بنابراین scriptها باید خروجی آن را 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

آخرین خط هر block به پرسشی متفاوت از پرسش‌های خطوط بالاتر پاسخ می‌دهد. dpkg -S و rpm -qf فقط بسته‌هایی را جست‌وجو می‌کنند که از قبل نصب شده‌اند؛ بنابراین به این پرسش پاسخ می‌دهند که «چه چیزی این فایل را در اینجا قرار داده است». apt-file search و dnf provides در repositoryها جست‌وجو می‌کنند؛ بنابراین به این پرسش پاسخ می‌دهند که «برای دریافت این فایل چه چیزی باید نصب کنم». apt-file در Ubuntu یک بسته جداگانه است و پیش از نخستین اجرا به sudo apt-file update نیاز دارد. dnf provides به مورد اضافی نیاز ندارد، هرچند اجرای نخست ممکن است کند باشد، زیرا dnf برای پاسخ‌دادن به این پرسش، فهرست فایل‌های repository را دانلود می‌کند.

برای فهرست‌کردن فایل‌های داخل بسته‌ای که هنوز نصب نکرده‌اید، از dnf repoquery -l nginx استفاده کنید. در سمت apt، این دستور apt-file list nginx است.

حذف خودکار، پاک‌کردن cache و نگه‌داشتن یک نسخه.

# 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 است، نه یک plugin.

جایی که نگاشت از کار می‌افتد: افزودن یک repository

این همان بخشی است که مدیران Ubuntu را به جست‌وجوی فرمانی می‌اندازد که وجود ندارد. در dnf هیچ add-apt-repository وجود ندارد و PPA نیز وجود ندارد. PPA سرویسی است که Launchpad اجرا می‌کند و Launchpad بخشی از زیرساخت Ubuntu است. در دنیای RPM چیزی برای میزبانی PPA وجود ندارد.

dnf در عوض، برای هر repository یک فایل متنی ساده در /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 کار می‌کند.

بیشتر vendorها این فایل را منتشر می‌کنند و از شما می‌خواهند آن را دریافت کنید. دستورالعمل‌های رسمی Docker برای RHEL و نسخه‌های بازسازی‌شده آن شامل 2 فرمان است:

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

خط اول لازم است، چون config-manager یک plugin است و بخشی از خود dnf نیست. اگر آن را اجرا نکنید، خط دوم با خطای No such command: config-manager شکست می‌خورد. هیچ مانعی وجود ندارد که همان فایل .repo را با curl به‌صورت دستی در /etc/yum.repos.d/ دانلود کنید؛ نتیجه یکسان خواهد بود. نصب Docker روی یک VPS همین کار را در سمت Debian توضیح می‌دهد؛ در آنجا گام معادل، یک source list و یک signing key را در 2 دایرکتوری متفاوت می‌نویسد.

تفاوت ساختار تعیین می‌کند وقتی repository دچار مشکل می‌شود کجا را بررسی کنید. apt تعریف‌ها را در /etc/apt/sources.list و /etc/apt/sources.list.d/ نگه می‌دارد و signing keyها جداگانه در /etc/apt/keyrings/ قرار دارند. dnf همه‌چیز را در /etc/yum.repos.d/ نگه می‌دارد و key به‌صورت یک URL داخل فایل .repo قرار دارد؛ بنابراین فقط یک فایل برای خواندن و یک فایل برای حذف وجود دارد. نسخه‌های جدیدتر apt با قالب deb822 به همین ساختار نزدیک شده‌اند و برای هر repository یک فایل .sources دارند. اگر با خطای duplicate sources مربوط به deb822 در Ubuntu مواجه شده‌اید، بخش apt این مشکل را از قبل دیده‌اید.

EPEL مخزنی است که بیشتر راهنماها فعال‌بودن آن را پیش‌فرض می‌گیرند

Extra Packages for Enterprise Linux (EPEL) پروژه‌ای از Fedora است که بسته‌های Fedora را برای RHEL و بازسازی‌های آن آماده می‌کند. EPEL نزدیک‌ترین گزینه به یک 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 به یکی از بسته‌های موجود در آن وابسته‌اند؛ بنابراین فعال‌کردن EPEL بدون CRB در همان لحظه خطا نمی‌دهد. خطا بعداً و هنگام نصب رخ می‌دهد و به وابستگی‌های حل‌نشده به بسته‌ای اشاره می‌کند که احتمالاً نام آن را نشنیده‌اید. ابتدا CRB را فعال کنید تا این دسته از خطاها برطرف شود.

در خود RHEL، CRB از طریق subscription شما ارائه می‌شود، نه از طریق config-manager؛ بنابراین برای این مرحله، دستورالعمل‌های خود Red Hat درباره EPEL را دنبال کنید. Fedora به هیچ‌یک از این موارد نیاز ندارد، زیرا مخزن اصلی آن بسته‌هایی را که EPEL به نسخه‌های قدیمی‌تر بازمی‌گرداند، از قبل در اختیار دارد. سیاست EPEL این است که هرگز بسته‌ای را که RHEL ارائه می‌کند جایگزین نکند؛ بنابراین افزودن این مخزن چیزی را که از قبل روی سرور شما نصب شده است تغییر نمی‌دهد.

dnf history undo؛ قابلیتی که apt ندارد

dnf تمام تراکنش‌ها را ثبت می‌کند و می‌تواند نسخهٔ معکوس یکی از آن‌ها را ایجاد کند.

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

dnf history فهرستی شماره‌گذاری‌شده از تراکنش‌ها را چاپ می‌کند و خط فرمانی را که هر تراکنش را آغاز کرده است نشان می‌دهد. undo تراکنش مخالف را ایجاد می‌کند: بسته‌هایی که آن تراکنش نصب کرده است حذف می‌شوند و بسته‌هایی که ارتقا داده شده‌اند، به نسخهٔ قبلی بازمی‌گردند. این همان قابلیتی است که کاربران apt پس از مهاجرت، بیش از همه کمبود آن را احساس می‌کنند.

این قابلیت محدودیت‌های واقعی دارد و پیش از اتکا به آن باید آن‌ها را بشناسید. undo فقط زمانی می‌تواند نسخهٔ یک بسته را دوباره نصب کند که آن نسخه هنوز در یک repository فعال وجود داشته باشد؛ بنابراین اگر build قدیمی از mirror حذف شده باشد، عملیات undo با خطای not-found شکست می‌خورد. rollback نیز در سطح package database متوقف می‌شود. اگر فرایند upgrade یک فایل configuration را بازنویسی کرده باشد، آن فایل همچنان بازنویسی‌شده باقی می‌ماند. اگر یک سرویس هنگام نخستین start، schema پایگاه داده را تغییر داده باشد، آن schema نیز تغییر‌یافته باقی می‌ماند. dnf فایل‌ها را به وضعیت قبلی برمی‌گرداند، اما داده‌های شما را بازنمی‌گرداند.

apt معادل این قابلیت را ندارد. /var/log/apt/history.log دقیقاً ثبت می‌کند که چه اتفاقی افتاده است، از جمله command line، اما خواندن یک log به‌معنای undo کردن آن نیست. بازیابی در apt باید به‌صورت دستی انجام شود: ابتدا apt list -a nginx را اجرا کنید تا ببینید archive هنوز کدام نسخه‌ها را نگه می‌دارد، سپس sudo apt install nginx=<exact version string> را اجرا کنید تا یکی از آن نسخه‌ها pin شود و sudo apt-mark hold nginx را اضافه کنید تا upgrade بعدی اصلاح شما را لغو نکند.

گروه‌های بسته معادل مستقیمی در apt ندارند

dnf می‌تواند مجموعه‌ای نام‌گذاری‌شده از بسته‌ها را با یک فرمان نصب کند.

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

راهنماهای قدیمی‌تر dnf groupinstall "Development Tools" را می‌نویسند. این نام مستعار در dnf 4 کار می‌کند و در dnf 5 حذف شده است؛ بنابراین عبارت دوکلمه‌ای dnf group install تنها شکل نوشتاری است که همه‌جا کار می‌کند. از همین شکل استفاده کنید و دیگر درباره آن فکر نکنید.

apt گروه ندارد. نزدیک‌ترین مفهوم در Debian، metapackage است؛ بسته‌ای است که در حالت معمول محتوای دیگری جز فهرستی از وابستگی‌ها ندارد، مانند build-essential. تفاوت عملی هنگام حذف مشخص می‌شود: حذف یک metapackage وابستگی‌های آن را نصب‌شده باقی می‌گذارد تا زمانی که apt autoremove را اجرا کنید؛ اما dnf group remove بسته‌های گروه را در همان تراکنش همراه با گروه حذف می‌کند.

به‌روزرسانی‌های unattended-upgrades و dnf-automatic

هر دو خانواده امکان نصب به‌روزرسانی‌ها را بدون ورود کاربر فراهم می‌کنند. این ابزارها، به‌جز هدف مشترک، قابلیت مشترک دیگری ندارند.

در Ubuntu و Debian، نام بسته unattended-upgrades است و در /etc/apt/apt.conf.d/50unattended-upgrades پیکربندی می‌شود؛ در این فایل، مبدأهایی را مشخص می‌کنید که ابزار اجازه دارد از آن‌ها بسته دریافت کند. راه‌اندازی unattended upgrades در Ubuntu این فایل پیکربندی و مسئله reboot مربوط به آن را توضیح می‌دهد.

در 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 فقط گزارش می‌دهد. هر یک از این unitها مقدار apply_updates را در /etc/dnf/automatic.conf بازنویسی می‌کند؛ بنابراین timer انتخابی شما از مقداری که فایل پیکربندی مشخص کرده است مهم‌تر است. نصب یک به‌روزرسانی، پردازشی را که همچنان کد قدیمی را اجرا می‌کند restart نمی‌کند. بنابراین پیش از آن‌که فرض کنید سرور patch شده است، بررسی کنید کدام‌یک از این به‌روزرسانی‌ها به reboot و کدام‌یک فقط به restart سرویس نیاز دارند.

برای محدود کردن این فرایند به اصلاحیه‌های امنیتی، upgrade_type = security را در /etc/dnf/automatic.conf تنظیم کنید. این فیلتر به انتشار security errata از سوی repositoryهای شما وابسته است؛ بنابراین ابتدا با dnf updateinfo list security بررسی کنید. اگر روی سیستمی که به‌روزرسانی‌های معوق دارد، نتیجه خالی باشد، metadata مربوط در دسترس نیست و در این حالت security هیچ چیزی نصب نمی‌کند.

در 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 همچنان در tutorialها دیده می‌شود، زیرا بیشتر دستورهای آن مستقیماً کار می‌کنند. yum install، yum remove و yum update همگی کار می‌کنند. یک عادت را بهتر است کنار بگذارید: yum-config-manager در سیستم‌های دارای dnf 4 هنوز به‌عنوان یک binary مستقل وجود دارد، اما dnf config-manager شکلی است که مستندات فعلی استفاده می‌کنند و هنگام ارتقای سیستم به dnf 5 نیز همچنان کار می‌کند.

dnf 4 و dnf 5: پیش از کپی‌کردن یک فرمان، نسخه را بررسی کنید

dnf 5 بازنویسی شده است و املای چند فرمان را تغییر داده است. Fedora 41 و نسخه‌های بعدی آن را به‌صورت dnf عرضه می‌کنند. توزیع‌های سازمانی بازسازی‌شده دیرتر به این نسخه مهاجرت کرده‌اند؛ بنابراین بر اساس نام توزیع حدس نزنید. روی سرور خودتان 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 پذیرفته نمی‌شود و به‌جای ایجاد مخزن، خطای نحوی دریافت می‌کنید. مورد دیگری که با آن روبه‌رو می‌شوید، فعال‌کردن مخزن است: dnf config-manager --set-enabled crb در dnf 4 به dnf config-manager setopt crb.enabled=1 در dnf 5 تبدیل می‌شود.

انتخابی که واقعاً اهمیت دارد

انتخاب توزیع سرور فقط بر اساس package manager، محور تصمیم‌گیری مناسبی نیست. dnf و apt کار یکسانی انجام می‌دهند و یادگیری واژگان آن‌ها بعدازظهر بیشتر طول نمی‌کشد. چیزی که روند کار شما را در طول سال تغییر می‌دهد، مدل انتشار پشت repository است. Fedora با سرعت زیادی پیش می‌رود و هر release تقریباً 13 ماه پس از انتشار، دریافت update را متوقف می‌کند. این وضعیت برای workstation مناسب است، اما برای سروری که نمی‌خواهید دوباره بسازید، مشکل‌ساز خواهد بود. Rocky Linux و AlmaLinux از RHEL پیروی می‌کنند؛ بنابراین یک بازه پشتیبانی 10 ساله و نسخه‌های packageای دریافت می‌کنید که عمداً ثابت نگه داشته می‌شوند. Ubuntu هر دو مدل را ارائه می‌دهد و تفاوت بین Ubuntu LTS و interim releaseها در سرور همان تصمیمی است که در دنیای apt گرفته می‌شود.

تا August 2026، همه این‌ها imageهای معمول VPS هستند. بازه پشتیبانی موردنظر خود را انتخاب کنید، سپس 10 دستور بالا را یاد بگیرید.

FAQ

معادل dnf برای apt update چیست؟

لازم نیست فرمانی اجرا کنید. dnf پیش از هر تراکنش بررسی می‌کند فرادادهٔ ذخیره‌شدهٔ آن چقدر قدیمی است و اگر منقضی شده باشد، نسخهٔ تازه‌ای را دانلود می‌کند؛ بنابراین dnf install روی سروری که یک ماه به آن دست نزده‌اید نیز بسته‌های فعلی را می‌بیند. sudo dnf makecache وجود دارد و این دانلود را اجباری می‌کند، اما کاربرد واقعی آن انتقال این تأخیر به زمانی است که خودتان انتخاب می‌کنید، نه آن‌که تأخیر به نصب بعدی منتقل شود. فرمانی که به پرسش «چه چیزی در انتظار من است؟» پاسخ می‌دهد dnf check-update است؛ این فرمان apt list --upgradable را اجرا می‌کند و اگر به‌روزرسانی موجود باشد، با وضعیت خروجی 100 پایان می‌یابد.

آیا در Rocky Linux یا Fedora معادلی برای PPA وجود دارد؟

خیر. آرشیوهای شخصی بسته، سرویس Launchpad هستند و Launchpad زیرساخت Ubuntu است؛ بنابراین add-apt-repository چیزی برای ترجمه‌کردن به معادل دیگری ندارد. معادل RPM، یک فایل .repo در مسیر /etc/yum.repos.d/ است که شامل یک نام، یک baseurl و یک gpgkey می‌شود. فروشندگان این فایل را برای شما منتشر می‌کنند و sudo dnf config-manager --add-repo <url> در dnf 4 یا sudo dnf config-manager addrepo --from-repofile <url> در dnf 5 آن را در محل مناسب دانلود می‌کند. برای نرم‌افزارهای اضافی عمومی، پاسخ معمولاً EPEL است که آن را با sudo dnf config-manager --set-enabled crb فعال می‌کنید و سپس sudo dnf install epel-release را اجرا می‌کنید.

آیا می‌توانم ارتقای dnf را که سرورم را از کار انداخته است برگردانم؟

بله، البته با محدودیت‌هایی. برای یافتن شمارهٔ تراکنش، sudo dnf history را اجرا کنید؛ سپس با sudo dnf history info <id> دقیقاً ببینید چه تغییراتی ایجاد شده است و در ادامه sudo dnf history undo <id> را اجرا کنید. اگر نسخهٔ قدیمی‌تر بسته دیگر در هیچ مخزن فعالی موجود نباشد، برگرداندن تغییرات شکست می‌خورد؛ زیرا dnf چیزی برای نصب مجدد ندارد. این کار فقط تغییرات بسته‌ها را معکوس می‌کند. فایل پیکربندی‌ای که در جریان ارتقا بازنویسی شده باشد یا پایگاه داده‌ای که سرویس هنگام اولین راه‌اندازی مهاجرت داده باشد، به همان شکل باقی می‌ماند. apt اصلاً فرمان معادلی ندارد و فقط رکورد موجود در /var/log/apt/history.log را نگه می‌دارد.

آیا yum هنوز روی Rocky Linux و AlmaLinux کار می‌کند؟

بله، زیرا /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 آن را به‌عنوان بسته‌ای که مستقلاً به آن نیاز دارید ثبت کند.