أوامر dnf البديلة لـ apt في Rocky Linux وFedora

الإجابة المختصرة

الانتقال من apt إلى dnf هو في الغالب تغيير في المصطلحات. يصبح apt install nginx هو dnf install nginx. ويصبح apt remove nginx هو dnf remove nginx. لا يوجد مكافئ مباشر لـ apt update، لأن dnf يحدّث بيانات المستودعات الوصفية تلقائياً عندما تصبح النسخة المخزنة مؤقتاً قديمة. النصف السهل من عملية التحويل يستغرق شاشة واحدة. أما النصف المفيد فيتمثل في العمليات الأربع التي لا يوجد لها مقابل مباشر: إضافة مستودع، التراجع عن عملية (transaction)، تثبيت مجموعة حزم، وتشغيل التحديثات التلقائية.

كل أمر أدناه مكتوب لتنفذه على خادمك الخاص. اقرأ ملخص العملية الذي يطبعه dnf قبل الإجابة بـ y، خاصة عند عمليات الحذف.

ما هي التوزيعات التي تستخدم dnf، والتي تستخدم apt

يُعد dnf مدير الحزم في Fedora، وفي Red Hat Enterprise Linux (RHEL)، وفي التوزيعات المبنية على RHEL مثل: Rocky Linux وAlmaLinux وCentOS Stream. بينما يُعد apt مدير الحزم في Debian وفي كل ما يشتق منها، وهو ما يعني غالباً Ubuntu في بيئات VPS. لا توجد إجابة ثالثة. إذا كانت قائمة صور النظام لدى مزود الخدمة توفر 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 إلى اقتراح حذف عشرات المكتبات معها. اقرأ القائمة قبل التأكيد.

تحديث البيانات الوصفية، والتحقق من التحديثات المعلقة، والترقية.

# 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 في كلتا الحالتين، لذا يجب على السكربتات تحليل مخرجاته.

سرد الحزم المثبتة، ومعرفة الحزمة التي تملك ملفاً معيناً.

# 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 للبحث عن أمر غير موجود. لا يوجد add-apt-repository في dnf، ولا توجد أرشيفات حزم شخصية (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 architecture) لديك أثناء التشغيل، لذا يعمل الملف نفسه على الإصدار 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 عبارة عن إضافة (plugin)، وليست جزءاً من dnf نفسه. إذا تخطيت هذا السطر، سيفشل السطر الثاني مع ظهور No such command: config-manager. لا شيء يمنعك من تنزيل ملف .repo نفسه باستخدام curl إلى /etc/yum.repos.d/ يدوياً، وستكون النتيجة متطابقة. يشرح تثبيت Docker على خادم VPS الجانب الخاص بـ Debian من المهمة نفسها، حيث تتضمن الخطوة المقابلة كتابة قائمة مصادر ومفتاح توقيع في دليلين مختلفين.

يحدد اختلاف التخطيط المكان الذي تبحث فيه عندما يسيء المستودع التصرف. يحتفظ 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، لذا اتبع تعليمات EPEL الخاصة بـ Red Hat لتلك الخطوة. لا تحتاج 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 أكثر من غيرها بعد الانتقال.

لهذه الميزة حدود حقيقية، ومن المهم معرفتها قبل الاعتماد عليها. لا يمكن لـ undo إعادة تثبيت إصدار حزمة إلا إذا كان لا يزال موجوداً في مستودع مفعّل، لذا بمجرد حذف الإصدار القديم من المرآة (mirror)، سيفشل التراجع مع خطأ "غير موجود". يتوقف التراجع أيضاً عند قاعدة بيانات الحزم. ملف الإعداد الذي أعادت الترقية كتابته يبقى كما هو، ومخطط قاعدة البيانات الذي قامت الخدمة بترحيله عند التشغيل الأول يبقى مرحّلاً. يعيد 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 مجموعات. أقرب مفهوم في Debian هو الحزمة الوصفية (metapackage)، وهي حزمة فارغة لا تحتوي إلا على قائمة من التبعيات، مثل build-essential. الفرق العملي يظهر عند الإزالة: إزالة حزمة وصفية تترك تبعياتها مثبتة حتى تشغّل apt autoremove، بينما يقوم dnf group remove بإزالة حزم المجموعة معها في نفس العملية.

unattended-upgrades و dnf-automatic

توفر كلتا العائلتين طريقة لتثبيت التحديثات دون الحاجة إلى تسجيل دخول أي مستخدم. لا تشترك الأداتان في أي شيء سوى الغرض.

في Ubuntu و Debian، الحزمة هي unattended-upgrades، ويتم إعدادها في /etc/apt/apt.conf.d/50unattended-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 فتقوم بإرسال تقارير فقط. تتجاوز كل وحدة من هذه الوحدات إعداد apply_updates الموجود في /etc/dnf/automatic.conf، لذا فإن المؤقت الذي تختاره أهم مما ينص عليه ملف الإعداد. لا يؤدي تثبيت التحديث إلى إعادة تشغيل ما لا يزال يعمل بالكود القديم، لذا من المفيد التحقق من أي من هذه التحديثات يتطلب إعادة تشغيل وأيها يتطلب إعادة تشغيل الخدمة فقط قبل افتراض أن الخادم قد تم تصحيحه.

لقصر التحديثات على الإصلاحات الأمنية فقط، اضبط upgrade_type = security في /etc/dnf/automatic.conf. يعتمد هذا الفلتر على نشر مستودعاتك لبيانات الأخطاء الأمنية (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 رابطاً رمزياً يشير إلى dnf. تحقق من نظامك:

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

تستمر صيغة yum القديمة في الظهور في الدروس التعليمية لأن معظمها لا يزال يعمل مباشرة. تعمل كل من yum install وyum remove وyum update بشكل طبيعي. هناك عادة واحدة يجدر بك التخلي عنها: لا يزال yum-config-manager موجوداً كملف ثنائي مستقل في أنظمة 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-driven)، لذا فإن العلم القديم --add-repo لم يعد مقبولاً، وستحصل على خطأ في الاستخدام بدلاً من إضافة المستودع. الأمر الآخر الذي ستواجهه هو تفعيل المستودع: حيث يصبح dnf config-manager --set-enabled crb في dnf 4 هو dnf config-manager setopt crb.enabled=1 في dnf 5.

الخيار الذي يهم فعلياً

اختيار توزيعة خادم بناءً على مدير الحزم وحده هو معيار خاطئ. فكلا dnf و apt يؤديان نفس العمل، ولا يستغرق تعلّم مفرداتهما أكثر من ظهيرة واحدة. ما يغيّر تجربتك خلال العام هو نموذج الإصدار الذي تتبعه المستودعات. تتحرك Fedora بسرعة، ويتوقف إصدارها عن تلقي التحديثات بعد حوالي ثلاثة عشر شهراً من صدوره، وهو أمر مناسب لمحطة عمل، لكنه مرهق لخادم لا ترغب في إعادة بنائه. تتبع Rocky Linux و AlmaLinux نظام RHEL، لذا تحصل على نافذة دعم تمتد لعشر سنوات وإصدارات حزم تظل ثابتة عمداً. توفر Ubuntu كلا الخيارين، و الفرق بين إصدارات Ubuntu LTS والإصدارات المؤقتة على الخادم هو نفس القرار الذي تتخذه داخل عالم apt.

اعتباراً من أغسطس 2026، تعتبر كل هذه التوزيعات صور VPS عادية. اختر نافذة الدعم التي تريدها، ثم تعلّم الأوامر العشرة المذكورة أعلاه.

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 تسببت في تعطل خادمي؟

نعم، ضمن حدود معينة. شغّل 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 مخصص للتوافق فقط، وفضّل استخدام dnf config-manager بدلاً من الملف الثنائي القديم yum-config-manager.

لماذا يريد dnf remove حذف الكثير من الحزم؟

لأن dnf يزيل التبعيات التي لا تحتاجها أي حزمة أخرى كجزء من نفس العملية، بينما يتركها apt remove مثبتة حتى تقوم بتشغيل apt autoremove بشكل منفصل. لذا فإن عملية إزالة تبدو صغيرة على Ubuntu قد تطبع قائمة طويلة على Rocky Linux. القائمة عادةً ما تكون صحيحة، لكن اقرأها قبل التأكيد. إذا كانت هناك حزمة في القائمة ترغب في الاحتفاظ بها، فقم بتثبيتها بشكل صريح أولاً حتى يسجلها dnf كحزمة مطلوبة بحد ذاتها.