بدائل أوامر apt في Rocky وFedora باستخدام dnf

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

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

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

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

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

عرض الحزم المثبتة، ومعرفة الحزمة المالكة لملف.

# 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، لأن التثبيت هو حالة في 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 رقم الإصدار الرئيسي وبنية وحدة المعالجة المركزية أثناء التشغيل، لذلك يعمل الملف نفسه مع الإصدار 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 من العملية نفسها، حيث تكتب الخطوة المكافئة قائمة مصادر ومفتاح توقيع في دليلين مختلفين.

يحدد اختلاف البنية المكان الذي تبحث فيه عند حدوث مشكلة في مستودع. يحتفظ 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 أولاً، وسيختفي هذا النوع من الأخطاء.

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

التحديثات غير التفاعلية و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. يعتمد هذا المرشح على نشر مستودعاتك للتنبيهات الأمنية، لذلك تحقّق أولاً باستخدام 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 القديمة تظهر في البرامج التعليمية لأن معظمها يمرّر الأوامر مباشرةً إلى dnf. تعمل yum install وyum remove وyum update جميعاً. لكن يجدر بك تغيير عادة واحدة: لا يزال yum-config-manager موجوداً كملف ثنائي مستقل في الأنظمة التي تستخدم dnf 4، إلا أن dnf config-manager هي الصيغة المستخدمة في الوثائق الحالية، وهي الصيغة التي تستمر في العمل عند ترقية النظام إلى dnf 5.

dnf 4 and dnf 5: check before you copy a command

dnf 5 is a rewrite, and it changed the spelling of several commands. Fedora 41 and later ship it as dnf. The enterprise rebuilds have been slower to switch, so do not guess from the distribution name. Run dnf --version on your own server and read the first line, because that number decides which syntax below you need.

The clearest demonstration comes from Docker, which publishes a different repository command for each. On RHEL and its rebuilds, with dnf 4:

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

On Fedora, with dnf 5:

sudo dnf config-manager addrepo --from-repofile https://download.docker.com/linux/fedora/docker-ce.repo

Same vendor, same job, different words. dnf 5 turned config-manager into a subcommand-driven tool, so the old --add-repo flag is not accepted and you get a usage error instead of a repository. The other one you will meet is enabling a repository: dnf config-manager --set-enabled crb on dnf 4 becomes dnf config-manager setopt crb.enabled=1 on dnf 5.

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

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

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

FAQ

ما المكافئ للأمر apt update في dnf؟

لا يوجد أمر يجب تشغيله. يتحقق dnf من عمر البيانات الوصفية المخزنة مؤقتاً قبل كل معاملة، وينزّل نسخة جديدة عند انتهاء صلاحيتها. لذلك يرى dnf install على خادم لم تستخدمه منذ شهر الحزم الحالية. يوجد sudo dnf makecache، وهو يفرض هذا التنزيل فعلاً، لكن استخدامه الأساسي هو نقل التأخير إلى وقت تختاره بدلاً من حدوثه أثناء عملية التثبيت التالية. الأمر الذي يجيب عن سؤال «ما الذي ينتظرني؟» هو dnf check-update، وهو يقابل apt list --upgradable ويخرج بحالة 100 عند توفر تحديثات.

هل يوجد مكافئ لـPPA على Rocky Linux أو Fedora؟

لا. أرشيفات الحزم الشخصية خدمة توفرها 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 على أنها مطلوبة بحد ذاتها.