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

پاسخ کوتاه

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

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

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

dnf مدیر بسته در Fedora، در Red Hat Enterprise Linux (RHEL) و در نسخه‌های بازسازی‌شده از RHEL یعنی Rocky Linux، AlmaLinux و CentOS Stream است. apt مدیر بسته در Debian و تمام توزیع‌های مشتق‌شده از آن است که در یک VPS تقریباً همیشه به معنای Ubuntu است. پاسخ سومی وجود ندارد. اگر لیست ایمیج‌های ارائه‌دهنده شما Rocky Linux یا AlmaLinux را پیشنهاد می‌دهد، شما با dnf سروکار دارید. اگر Ubuntu را پیشنهاد می‌دهد، شما با apt سروکار دارید.

فرمت بسته از ابزار مربوط به خود پیروی می‌کند. 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 ممکن است منجر به پیشنهاد حذف ده‌ها کتابخانه همراه آن شود. پیش از تأیید، لیست را مطالعه کنید.

به‌روزرسانی متادیتا، بررسی موارد در انتظار و ارتقای سیستم.

# 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 یک نام مستعار قدیمی برای همان دستور است و همچنان کار می‌کند.

اگر در حال اسکریپت‌نویسی هستید، یک جزئیات مهم است: dnf check-update در صورت وجود به‌روزرسانی با وضعیت 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 است.

حذف خودکار، پاکسازی کش، نگهداری نسخه (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 است و نه یک افزونه.

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

این بخشی است که مدیران سیستم Ubuntu را به دنبال دستوری می‌فرستد که وجود خارجی ندارد. هیچ add-apt-repository در dnf وجود ندارد و هیچ Personal Package Archive یا همان 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 کار می‌کند.

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

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/ دانلود کنید؛ نتیجه دقیقاً یکسان خواهد بود. نصب Docker روی یک VPS همین کار را برای سمت Debian توضیح می‌دهد، جایی که مرحله معادل آن، نوشتن یک source list و یک کلید امضا در دو دایرکتوری متفاوت است.

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

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

پروژه Extra Packages for Enterprise Linux (EPEL) متعلق به Fedora است و بسته‌های Fedora را برای RHEL و توزیع‌های مبتنی بر آن بازسازی می‌کند. این مخزن نزدیک‌ترین معادل به یک 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 از طریق اشتراک شما فراهم می‌شود و نه از طریق config-manager؛ بنابراین برای این مرحله، دستورالعمل‌های رسمی Red Hat برای EPEL را دنبال کنید. Fedora به هیچ‌کدام از این مراحل نیاز ندارد، زیرا مخازن اصلی آن از قبل شامل مواردی است که EPEL برای سایر توزیع‌ها بازسازی (backport) می‌کند. سیاست EPEL این است که هرگز بسته‌های ارائه‌شده توسط RHEL را جایگزین نکند، بنابراین افزودن این مخزن هیچ تغییری در بسته‌های نصب‌شده روی سرور شما ایجاد نخواهد کرد.

دستور dnf history undo، قابلیتی که در apt وجود ندارد

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

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

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

این قابلیت محدودیت‌های واقعی دارد که پیش از تکیه بر آن، باید از آن‌ها آگاه باشید. دستور undo تنها زمانی می‌تواند یک نسخه از بسته را دوباره نصب کند که آن نسخه همچنان در یکی از مخازن فعال موجود باشد؛ بنابراین به محض اینکه بیلد قدیمی از روی mirror حذف شود، عملیات undo با خطای not-found شکست می‌خورد. بازگردانی (Rollback) تنها در سطح پایگاه‌داده بسته‌ها عمل می‌کند. فایل پیکربندی که در حین ارتقا بازنویسی شده است، به همان حالت بازنویسی‌شده باقی می‌ماند و طرحواره (schema) پایگاه‌داده‌ای که یک سرویس در اولین اجرا مهاجرت داده است، به حالت قبل برنمی‌گردد. dnf فایل‌ها را به جای خود بازمی‌گرداند، اما داده‌های شما را بازیابی نمی‌کند.

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

گروه‌های بسته معادل 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 هیچ گروهی ندارد. نزدیک‌ترین مفهوم در دبیان، metapackage است؛ بسته‌ای که در غیر این صورت خالی است و تنها محتوای آن فهرستی از وابستگی‌هاست، مانند build-essential. تفاوت عملی در نحوه حذف آن‌هاست: حذف یک metapackage، وابستگی‌های آن را تا زمانی که دستور apt autoremove را اجرا نکنید نصب‌شده باقی می‌گذارد، در حالی که dnf group remove بسته‌های گروه را در همان تراکنش حذف می‌کند.

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

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

در Ubuntu و Debian، بسته مورد نظر unattended-upgrades است که در /etc/apt/apt.conf.d/50unattended-upgrades پیکربندی می‌شود؛ در این فایل، مبدأهایی (origins) که مجاز به دریافت به‌روزرسانی از آن‌ها هستید را فهرست می‌کنید. راه‌اندازی unattended upgrades در Ubuntu این فایل پیکربندی و مسئله ریبوت پس از به‌روزرسانی را پوشش می‌دهد.

در 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 فقط گزارش می‌دهد. هر یک از این unitها تنظیمات apply_updates در /etc/dnf/automatic.conf را نادیده می‌گیرند، بنابراین تایمری که انتخاب می‌کنید اهمیت بیشتری نسبت به محتوای فایل پیکربندی دارد.

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

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

dnf 4 و dnf 5: پیش از کپی کردن دستور، بررسی کنید

نسخه dnf 5 یک بازنویسی کامل است و املای چندین دستور در آن تغییر کرده است. Fedora 41 و نسخه‌های پس از آن، این ابزار را با dnf عرضه می‌کنند. توزیع‌های سازمانی (Enterprise rebuilds) در مهاجرت به این نسخه کندتر عمل کرده‌اند، بنابراین صرفاً بر اساس نام توزیع حدس نزنید. دستور dnf --version را روی سرور خود اجرا کنید و خط اول خروجی را بخوانید؛ چرا که آن عدد تعیین می‌کند به کدام دستورات زیر نیاز دارید.

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

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

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

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

FAQ

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

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

آیا معادل PPA در 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 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 یک لینک نمادین (symbolic link) به dnf است. این موضوع را در سیستم خود با ls -l /usr/bin/yum تأیید کنید. تایپ کردن yum install httpd در واقع dnf را اجرا می‌کند، بنابراین اکثر آموزش‌های قدیمی همچنان کارایی دارند. اسکریپت‌ها و مستندات جدید را با dnf بنویسید، زیرا نام yum فقط برای سازگاری است و استفاده از dnf config-manager را به جای باینری قدیمی‌تر yum-config-manager ترجیح دهید.

چرا dnf remove می‌خواهد بسته‌های زیادی را حذف کند؟

زیرا dnf وابستگی‌هایی را که دیگر مورد نیاز نیستند، به عنوان بخشی از همان تراکنش حذف می‌کند، در حالی که apt remove آن‌ها را نصب‌شده باقی می‌گذارد تا زمانی که جداگانه apt autoremove را اجرا کنید. بنابراین حذفی که در Ubuntu کوچک به نظر می‌رسد، ممکن است در Rocky Linux لیست بلندی را نمایش دهد. این لیست معمولاً درست است، اما پیش از تأیید آن را بخوانید. اگر بسته‌ای در آن لیست وجود دارد که می‌خواهید حفظ کنید، ابتدا آن را به‌طور صریح نصب کنید تا dnf آن را به عنوان بسته‌ای که مستقلاً مورد نیاز است، ثبت کند.