EPEL وCRB في Rocky وAlma: حل خطأ dnf

لماذا لا يستطيع dnf العثور على الحزمة التي تريدها

EPEL وCRB هما المستودعان اللذان لا يوفّرهما لك خادم Rocky Linux أو AlmaLinux حديث التثبيت، ولذلك يجيب dnf install htop على خادم جديد بـ No match for argument: htop ثم يعرض Error: Unable to find a match: htop. لا يوجد عطل، ولا يوجد mirror متوقف. يوفّر التوزيع الأساسي مجموعة صغيرة من الحزم عمداً، ويكون CRB موجوداً لكنه معطّل، بينما EPEL مستودع مجتمعي منفصل يجب أن تضيفه.

في Ubuntu توجد الحزمة نفسها في universe، ويكون universe مفعّلاً في كل صورة سحابية تقريباً، لذلك لا يبرز هذا السؤال. تقسّم عائلة Red Hat حزمها بطريقة مختلفة، وتبدأ بعدد أقل من الحزم المفعّلة. يتكوّن الحل من ثلاثة أوامر. أما بقية هذا الدليل فهي الجزء الذي لا يخبرك به أحد في أسبوعك الأول: ما الذي تعد به هذه المستودعات، وما الذي لا تعد به، وكيف تمنع مستودعاً تابعاً لجهة خارجية من السيطرة بهدوء على نظامك الأساسي.

كيف اختُبرت هذه الأوامر. تعمل حاويات اختبار الأوامر لدينا على Ubuntu فقط، لذلك لم تُنفَّذ أوامر dnf أدناه على أجهزة الاختبار الخاصة بنا. وهي تتبع وثائق Rocky Linux وAlmaLinux. تذكر كل خطوة الناتج المتوقع ظهوره، لذلك تحقّق من كل خطوة على خادمك بدلاً من لصق الكتلة كاملة دفعة واحدة.

ما هي BaseOS وAppStream وCRB؟

BaseOS هو نظام التشغيل نفسه: النواة وglibc وsystemd ومكونات userland الأساسية. تكون الإصدارات هنا ثابتة طوال دورة الإصدار الرئيسي، وتُطبَّق إصلاحات الأمان على هذه الإصدارات الثابتة عبر backporting. رقم إصدار يبدو قديماً بسنوات في BaseOS لا يعني أن الحزمة لم تحصل على التصحيحات. بل يعني أنها إصدار قديم حصل على التصحيحات، وهذا هو جوهر توزيعة المؤسسات.

يحتوي AppStream على المكونات التي تشغّلها فوق النظام: خوادم الويب وقواعد البيانات وبيئات تشغيل اللغات والمحررات ووكلاء المراقبة. في الإصدار 8، قُدِّم جزء كبير من AppStream على شكل modules مع alternate streams، لذلك كان dnf module list مهماً، وكنت تختار، مثلاً، أحد مسارات PHP. أسقط الإصدار 9 معظم modularity، لذلك تحصل عادةً في Rocky 9 وAlma 9 على إصدار واحد من المكوّن، ولا تحتاج إلى تفعيل module أولاً.

يكون Extras مفعّلاً افتراضياً وهو صغير جداً. ويحتوي في الغالب على حزم release لمستودعات أخرى، ومنها تأتي epel-release نفسها. ولهذا التفصيل أهمية: فلن تحتاج أبداً إلى الوثوق بعنوان URL عشوائي لتثبيت EPEL على Rocky أو Alma.

CRB هو مستودع CodeReady Builder، وكان يُسمّى PowerTools في الإصدار 8. ويحتوي على جانب البناء في التوزيعة: ترويسات التطوير والمكتبات الساكنة وأدوات الاختبار والتوثيق التي تحتاج إليها الحزم وقت البناء. وهو موجود مسبقاً على mirror لكنه معطّل افتراضياً. في منتج Red Hat نفسه، يُسمّى المحتوى ذاته CodeReady Linux Builder، ويأتي ضمن الاشتراك، وتوضح Red Hat أنه غير مشمول بالدعم. وترث Rocky وAlma المحتوى نفسه والإعداد الافتراضي المعطّل.

بالنسبة إلى القراء القادمين من Debian أو Ubuntu: تجمع main حزم runtime وترويسات -dev في archive واحد، لذلك لا يوجد CRB لتفعيله هناك. وأقرب نظير إلى EPEL هو universe، وهو مُدار من المجتمع ولا يتضمن أي التزام بالدعم من البائع.

ما هو EPEL، ومن يقف وراءه

يرمز EPEL إلى Extra Packages for Enterprise Linux. وهو مشروع تابع لـFedora: حزم موجودة في Fedora، يُعاد بناؤها للإصدار المؤسسي الحالي، وتتولى صيانتها مجموعة الاهتمام الخاصة بـEPEL، التي تتكوّن في معظمها من متطوعين من مجتمع Fedora. تستضيف Red Hat بنية البناء والمرايا، ويصون بعض مهندسي Red Hat حزماً فيه. وتنتهي العلاقة عند هذا الحد. EPEL ليس منتجاً من Red Hat. لا يوجد عقد دعم ولا اتفاقية مستوى خدمة (SLA) وراء حزمة EPEL، سواء على RHEL أو على توزيعة معاد بناؤها.

تجعل سياسة واحدة تفعيل EPEL آمناً أصلاً: يجب ألا تستبدل حزمة EPEL حزمةً من التوزيعة الأساسية. إذا كان AppStream يوفّر nginx، فلن يوفّرها EPEL. يفرض هذه القاعدة الأشخاص الذين يراجعون حزم EPEL، ولذلك فهي التزام يخص EPEL فقط. ولا تحميك من أي شيء آخر تضيفه لاحقاً.

يختلف أيضاً التزام مدة الصيانة عن التوزيعة الأساسية، وهذا ما يسبب المشكلات في السنة الثالثة. تُجمَّد نسخة حزمة BaseOS طوال مدة السنوات العشر للإصدار الرئيسي. أما صائن EPEL فيلتزم بفترة أقصر بكثير: إصدار RHEL فرعي واحد على الأقل أو 13 شهراً، أيهما أقصر. عملياً، تُصان معظم الحزم مدة أطول بكثير من ذلك. تُسحب بعض الحزم عندما يتوقف الصائن عن متابعتها، وتنتقل بعض الحزم إلى إصدار رئيسي جديد في منتصف عمر توزيعتك، لأن EPEL يتبع Fedora. لذلك قد تمنحك عملية dnf upgrade اعتيادية إصداراً رئيسياً جديداً من أداة EPEL على جهاز كنت تظنه مستقراً، وقد تتوقف حزمة تعتمد عليها عن تلقي التحديثات دون إعلان يصل إليك. كما لا يسري الإصدار الجديد على خدمة تعمل بالفعل، ولذلك تخبرك needs-restarting بالعمليات التي لا تزال تستخدم الملف التنفيذي القديم بعد اكتمال المعاملة.

هناك نتيجة أخرى ينبغي معرفتها قبل تفعيل EPEL: يُبنى EPEL مقابل أحدث إصدار فرعي من RHEL. إذا أبقيت خادماً على إصدار فرعي أقدم، باستخدام مرآة مجمّدة أو مستودع إصدار نقطة تابعاً لمورّد، فقد تتطلب حزمة EPEL مكتبة أساسية أحدث من المكتبة الموجودة لديك. يعرض dnf ذلك على أنه تبعية مفقودة، وقد يبدو كأنه مشكلة في المرآة، بينما هو في الحقيقة مشكلة اختلاف في الإصدارات.

تمكين CRB وتثبيت EPEL على Rocky أو Alma

sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --set-enabled crb
sudo dnf install -y epel-release
sudo dnf makecache
dnf repolist --enabled

يجب أن يعرض dnf repolist --enabled الآن baseos وappstream وextras وcrb وepel. قد ترى أيضاً إدخال epel-cisco-openh264 صغيراً، ويضيفه epel-release. إذا كان crb مفقوداً من هذه القائمة، فلم تنجح خطوة التمكين، ويشرح القسم التالي السبب.

في Rocky 8 وAlma 8، لا يزال المستودع يسمى PowerTools، لذلك يصبح الأمر الأوسط sudo dnf config-manager --set-enabled powertools. معرّفات المستودعات حساسة لحالة الأحرف. وتكتب وثائق CentOS 8 الأقدم الاسم PowerTools بأحرف كبيرة، وهذا لن يطابق المعرّف. في AlmaLinux 10، يكون مستودع CRB مفعّلاً افتراضياً بدءاً من 10.0، بعد التغيير الذي أُجري في سبتمبر 2025. لذلك لا تحتاج هناك إلا إلى خطوة epel-release.

يأتي epel-release من extras، وهو مفعّل بالفعل. لذلك لا يوجد عنوان URL يجب الوثوق به، ولا مفتاح يجب استيراده يدوياً. تكتب الحزمة /etc/yum.repos.d/epel.repo وتثبّت مفتاح توقيع EPEL ضمن /etc/pki/rpm-gpg/. أكّد وجود gpgcheck=1 في ذلك الملف، وتجاهل أي دليل يطلب منك تجاوز خطأ توقيع باستخدام --nogpgcheck. يعني فشل التحقق من التوقيع أن الحزمة ليست كما تدّعي، أو أن ساعتك غير مضبوطة.

على Rocky، يثبّت epel-release أيضاً أداة مساعدة صغيرة في /usr/bin/crb. لذلك تنفّذ sudo crb enable وcrb status المهمة نفسها من دون الإضافة. تحقّق من وجودها باستخدام command -v crb قبل الاعتماد عليها، لأنها لا تكون موجودة في كل فرع من كل إعادة بناء.

لإثبات إمكانية الوصول إلى EPEL، وليس مجرد ظهوره في القائمة، اطلب منه حزمة لا يوفرها إلا هو:

dnf repoquery --repo=epel htop

يعرض ذلك اسم الحزمة وإصدارها ومعمارية النظام. يعني عدم ظهور أي مخرجات أن المستودع مفعّل لكنه لا يعيد نتائج. ويكون السبب عادةً مشكلة في المرآة أو البيانات الوصفية، لا مشكلة في الإعداد. لذلك جرّب sudo dnf clean all && sudo dnf makecache بعد ذلك.

لماذا يعرض dnf رسالة تفيد بعدم وجود الأمر config-manager

هذا أول ما يربك المستخدمين، ويحدث تحديداً في الصور التي يوفّرها معظم مزوّدي VPS.

No such command: config-manager. Please use /usr/bin/dnf --help
It could be a DNF plugin command, try: "dnf install 'dnf-command(config-manager)'"

config-manager هو مكوّن إضافي، وليس أمراً فرعياً مضمّناً في dnf. يُوفَّر ضمن dnf-plugins-core، الذي تُثبّته عمليات تثبيت الخوادم الكاملة، بينما لا تتضمنه الصور المصغّرة والصور السحابية وصور الحاويات. تعمل التوصية التي يعرضها dnf نفسه لأن الحزمة تعلن عن هذه الإمكانية الافتراضية:

sudo dnf install -y 'dnf-command(config-manager)'

اكتبها بين علامتي اقتباس. الأقواس جزء من صياغة shell، لذلك تؤدي النسخة غير المقتبسة إلى خطأ في الصياغة بدلاً من خطأ من dnf.

إذا تعذّر تثبيت المكوّن الإضافي لأن المستودع الذي تحتاج إليه هو المستودع المعطّل، فعدّل الملف بدلاً من ذلك. حدّد الملف الذي يحتوي على القسم، وافتحه، واضبط enabled=1 ضمن [crb]:

grep -rl crb /etc/yum.repos.d/

هذا هو بالضبط ما يكتبه config-manager، لذلك لا تفقد شيئاً عند تنفيذ ذلك يدوياً. يؤكد dnf repolist --enabled النتيجة.

لن تُثبَّت بعض حزم EPEL قبل تفعيل CRB

يعرض الفخ الشائع الثاني خطأً لا يذكر CRB مطلقاً. تفشل حزمة EPEL التي ترتبط بمكتبة متوفرة في CRB فقط أثناء حل التبعيات، وتذكر الرسالة اسم المكتبة واسم الحزمة التي تحتاج إليها:

Error:
 Problem: conflicting requests
  - nothing provides libexample.so.0()(64bit) needed by examplepkg-1.4-2.el9.x86_64 from epel

السبب هو أن CRB معطّل، لذلك لا يستطيع dnf الوصول إلى المستودع الوحيد الذي يوفر تلك المكتبة. تحقّق من الأمرين بالترتيب:

dnf repolist --enabled
dnf --enablerepo=crb repoquery --whatprovides 'libexample.so.0()(64bit)'

إذا سمّى الأمر الثاني حزمة بينما يظل التثبيت العادي يفشل، فهذا يعني أن CRB غير مفعّل. هذا النوع من الأخطاء شائع بما يكفي لأن AlmaLinux فعّل CRB افتراضياً في الإصدار 10 تحديداً لمنع حدوثه. يعمل --enablerepo=crb أيضاً كخيار لمرة واحدة أثناء عملية تثبيت واحدة، لكن اترك CRB مفعّلاً بشكل دائم إذا كنت تستخدم EPEL، لأن تحديث EPEL التالي قد يجلب تبعية جديدة من CRB من دون تحذير مسبق.

من أي مستودع جاءت هذه الحزمة؟

بعد مرور بضعة أسابيع مع تفعيل أربعة مستودعات، يتوقف السؤال المفيد عن كونه: ما الحزم المثبّتة؟ ويصبح: من أين جاءت؟

dnf repolist --all
dnf info htop
dnf repoquery --installed --qf '%{from_repo} %{name}' | sort | uniq -c | sort -rn
dnf repository-packages epel list installed

يعرض dnf info على حزمة مثبّتة سطراً من نوع From repo. ويعرض dnf list installed المعلومات نفسها في العمود الثالث، مع وجود @ في بدايته. لذلك يعني @epel أنّ الحزمة ثُبّتت من EPEL، بينما يعني @System أنّ dnf لا يعرف مصدرها، وهذا يعني عادةً أنّ شخصاً ما شغّل rpm -i على ملف تم تنزيله. ويعرض السطر repoquery عدداً لكل مستودع. وهذه أسرع طريقة لاكتشاف أنّ خادماً ورثته يحتوي على أربعين حزمة من مستودع لم تسمع به من قبل. ويسرد الأمر الأخير بالضبط ما قدّمه لك أحد المستودعات. وتحتاج إلى هذه القائمة قبل أن تقرر إزالته.

العادة المقابلة في apt هي apt-cache policy <package>. ومن المفيد إبقاء المقابلات بين أوامر dnf وapt مفتوحة في علامة تبويب ثانية خلال الشهر الأول، لأن المفاهيم تتطابق بوضوح حتى عندما تختلف الرايات.

كيف أمنع مستودعاً تابعاً لجهة خارجية من استبدال حزمة أساسية؟

يتعهد EPEL بعدم فعل ذلك. ولا يقدّم أي مستودع آخر هذا التعهد. قد يوفّر مستودع تابع لمورّد قاعدة بيانات أو وكيلاً أو بيئة تشغيل لغة برمجة نسخته الخاصة من مكتبة يوفّرها BaseOS أيضاً، وسيثبّتها dnf لأن قاعدته الافتراضية بسيطة: يفوز الإصدار الأعلى، بصرف النظر عن مصدره.

تنجز أداتان معظم العمل، وكلتاهما موجودتان في ملف المستودع ضمن /etc/yum.repos.d/.

يحدد priority= المستودع الذي يفوز عندما يحمل أكثر من مستودع الاسم نفسه للحزمة. تفوز الأرقام الأقل، والقيمة الافتراضية هي 99، لذلك امنح مستودعاتك الأساسية رقماً منخفضاً وأي مستودع تابع لجهة خارجية رقماً مرتفعاً. عندئذ يختار dnf الحزمة الأساسية حتى عندما يكون إصدار الجهة الخارجية أحدث. يتولى dnf الحديث ذلك بنفسه، لذلك لم تعد حزمة yum-plugin-priorities المنفصلة من حقبة CentOS 7 جزءاً من الحل.

يُعد includepkgs= الخيار الأقوى بين خيارات التصفية. يحظر excludepkgs= الحزم المحددة بالاسم من المستودع، ما يتطلب منك توقّع ما قد يوفّره. أما includepkgs= فيعكس ذلك: يُسمح لهذا المستودع بتوفير هذه الأسماء فقط، ولا شيء غيرها. إذا كان يجب ألا يوفّر مستودع مورّد إلا وكيله الخاص، فتكفيه سطر واحد.

[vendor-tools]
name=Vendor tools for EL9
baseurl=https://packages.example.com/el9/x86_64/
enabled=1
gpgcheck=1
gpgkey=https://packages.example.com/RPM-GPG-KEY-vendor
priority=90
includepkgs=vendor-agent,vendor-agent-plugins

في الإصدار 8، هناك إعداد إضافي يجب معرفته. قد تصبح حزمة من مستودع تابع لجهة خارجية مخفية عندما توفّر وحدة AppStream الاسم نفسه، ويخبر module_hotfixes=1 في قسم ذلك المستودع dnf بالتوقف عن تصفيتها. إذا كانت الحزمة ظاهرة لـ dnf repoquery لكنها لا تُثبَّت على نظام بالإصدار 8، فهذا هو السبب غالباً. أُزيلت جميع الوحدات تقريباً في الإصدار 9، لذلك نادراً ما يظهر هذا الأمر هناك.

لتثبيت حزمة واحدة على إصدار واحد، ثبّت python3-dnf-plugin-versionlock واستخدم sudo dnf versionlock add <package>. وهذا يعادل apt-mark hold. انتبه إلى اختلاف يربك من ينتقل من Debian: يفوز Pin-Priority الأعلى في apt، بينما يفوز priority الأقل في dnf.

لماذا يجعل خلط المستودعات المجاورة لـRHEL الخادم غير قابل للترقية

تتقارب Rocky وAlma وCentOS Stream وOracle Linux وRHEL بما يكفي لتثبيت حزم بعضها على بعض، لكنها تختلف بما يكفي لتصبح النتيجة نظاماً لا يستطيع أحد دعمه. سبب هذا التقارب، وسبب تقدّم Stream على RHEL بدلاً من وجوده إلى جانبه، موضّحان في قصة انقسام Red Hat Linux إلى Fedora وRHEL وما آل إليه CentOS.

الآلية تعتمد على أرقام الإصدارات. يسبق CentOS Stream 9 إصدار RHEL 9، لذلك فإن توجيه جهاز Rocky 9 إلى مستودع Stream، ولو مرة واحدة أو لحزمة واحدة، يترك لديك حزم تسبق إصدارات أي حزمة ستصدرها Rocky لاحقاً. عندما يصل الإصدار الفرعي التالي من Rocky، يكون إصدار تلك الحزمة أقدم من الإصدار المثبت لديك، لذلك لن يتعامل dnf upgrade معه. يعمل الجهاز الآن بمزيج لم يختبره أحد، ويظل كذلك بهدوء لسنوات بينما تفترض أنه محدّث.

يظهر الخلل عندما يعرض dnf upgrade عدم وجود ما يجب فعله، بينما يقترح sudo dnf distro-sync تخفيض إصدارات قائمة طويلة من الحزم. أداة الإصلاح هي distro-sync: فهي تجبر كل حزمة مثبتة على مطابقة ما تعرضه المستودعات المفعّلة فعلياً، بما في ذلك تخفيض الإصدارات. عطّل المستودع الخارجي أولاً، ثم شغّل الأداة، واقرأ قائمة التغييرات المقترحة قبل قبولها. يفشل الإصلاح عندما لا تعود حزمة RPM الأقدم موجودة على المرآة، وعندها تكون إعادة بناء الخادم من صورة نظيفة أسرع وأكثر أماناً من محاولة حل المشكلة باستخدام محلّل الاعتماديات.

تُعد بقايا ELevate شكلاً شائعاً آخر من هذه المشكلة. ELevate أداة ترحيل AlmaLinux المبنية على Leapp، وتُستخدم لنقل جهاز CentOS 7 إلى إصدار أحدث أو للتحويل بين التوزيعات المعاد بناؤها. يترك الترحيل المتعجل ملفات مستودعات EL7 في /etc/yum.repos.d/، كما يترك حزم EL7 مثبتة. اعثر عليها باستخدام rpm -qa | grep el7. كل واحدة منها حزمة لا يستطيع أي مستودع مفعّل تحديثها، وسيعرضها تشغيل Leapp لاحقاً على أنها حزم لا يستطيع ربطها، مما يتحول إلى عائق للترقية يجب إزالته يدوياً. أزلها بينما يكون الخادم مستقراً، لا في اليوم الذي تحتاج فيه إلى الترقية الرئيسية التالية.

يُعد حجب مستودع مورّد لحزمة AppStream النسخة الأخف من المشكلة نفسها، ويُصلحها سطر includepkgs الوارد أعلاه. تُعد أدوات الحاويات الحالة المعتادة، لأن containerd.io من مستودع Docker الخاص يتعارض مع runc من AppStream، ولذلك يجب إزالة أحدهما. اتخذ القرار مرة واحدة، وسجّل الاستثناء، واتبع ترتيباً معروفاً وسليماً: يوضّح دليل تثبيت Docker على Rocky Linux حزم التوزيعة التي يجب إزالتها أولاً.

ترجمة أوامر apt إلى dnf الخاصة بالمستودعات

• /etc/apt/sources.list.d/*.sources تصبح /etc/yum.repos.d/*.repo، ويمكن لملف واحد أن يحتوي على عدة [sections]، ولكل منها معرّف خاص.
• add-apt-repository universe تصبح dnf install epel-release، مع اختلاف أن universe لا تزال ضمن أرشيف Ubuntu نفسه، بينما EPEL مشروع منفصل.
• لا يوجد مقابل مباشر لـ apt update، ويجب تذكّر ذلك. يحدّث dnf البيانات الوصفية وفق جدوله الخاص، ويفرض dnf makecache تحديثها فوراً.
• apt-cache policy <pkg> تصبح dnf info <pkg>، مع إضافة dnf list --showduplicates <pkg> لعرض كل إصدار متاح.
• apt-mark hold تصبح dnf versionlock add، انطلاقاً من python3-dnf-plugin-versionlock.
• يصبح تثبيت الإصدار في /etc/apt/preferences.d/ هو priority= ضمن قسم المستودع، مع استخدام الأرقام بالاتجاه المعاكس.
• dpkg -S /path/to/file تصبح rpm -qf /path/to/file.

تُنقل التحديثات التلقائية باعتبارها فكرة، لا صيغة أوامر، لأنه لا يوجد unattended-upgrades هنا. يوضّح dnf-automatic على Rocky وAlma المؤقت وملف الإعداد ومسألة إعادة التشغيل من عدمها.

أبقِ قائمة المستودعات قصيرة

فعّل CRB وثبّت epel-release، ثم دوّن ما فعلته وسببه، سواء في نظام إدارة الإعدادات لديك أو في ملف عادي على الخادم. تصبح هذه الملاحظة أهم مما قد يبدو عندما يكون عمر الخادم ثلاث سنوات ويتولى شخص آخر إدارته.

ابحث قبل أن تضيف مستودعاً. شغّل dnf search، ثم dnf info، وفكّر في إضافة مستودع جديد بعد ذلك فقط. جزء كبير على نحو مفاجئ مما يفعّله الناس من EPEL موجود أصلاً في AppStream. وتُعد مراقبة النظام أوضح مثال على ذلك، لأن Performance Co-Pilot متاح في المستودعات الأساسية ولا يحتاج إلى أي مكوّن من جهة خارجية. كل مستودع إضافي يعني جهة أخرى يمكنها تزويدك بحزمة في أي يوم، وكل مستودع منها يجعل الترقية الرئيسية التالية أصعب.

إذا كنت لا تزال تختار بين التوزيعتين، فهذه البنية متطابقة في كلتيهما، ويتصرف epel-release بالطريقة نفسها. أما الاختلافات الفعلية فتوجد في مواضع أخرى: يشرح مقارنة Rocky Linux وAlmaLinux فلسفة إعادة البناء، لأن AlmaLinux يستهدف الآن التوافق مع ABI (واجهة التطبيق الثنائية) بدلاً من إعادة البناء سطراً بسطر.

FAQ

كيف أفعّل EPEL على Rocky Linux 9 أو AlmaLinux 9؟

شغّل sudo dnf install -y dnf-plugins-core، ثم sudo dnf config-manager --set-enabled crb، ثم sudo dnf install -y epel-release. تحقّق باستخدام dnf repolist --enabled، الذي يجب أن يعرض baseos وappstream وextras وcrb وepel. فعّل CRB قبل تثبيت حزم EPEL، لأن كثيراً منها يعتمد على مكتبات لا يوفرها إلا CRB. في الإصدار 8 يكون معرّف المستودع powertools بدلاً من crb.

هل تفعيل EPEL على خادم إنتاج آمن؟

يُستخدم EPEL على نطاق واسع، ويعتمد على سياسة تمنع حزم EPEL من استبدال أي حزمة من التوزيعة الأساسية. لذلك لا يغيّر تفعيله ما يوفّره BaseOS أو AppStream. لكن توجد ملاحظة تتعلق بالدعم: EPEL مشروع Fedora تطوّعي ولا يوفّر اتفاقية مستوى خدمة، وقد يلتزم المشرف بالحزمة لمدة لا تتجاوز إصداراً فرعياً واحداً من RHEL أو 13 شهراً. احتفظ بجرد باستخدام dnf repository-packages epel list installed، واستخدم dnf versionlock مع أي حزمة من EPEL تعتمد عليها خدمة متاحة للعملاء.

لماذا يعرض dnf الرسالة no such command: config-manager؟

لأن config-manager إضافة لـ dnf وليست أمراً مضمّناً، ولأن صور الأنظمة المصغّرة أو الحاويات تُطرح من دون dnf-plugins-core. وتوضح الرسالة نفسها طريقة الإصلاح: sudo dnf install -y 'dnf-command(config-manager)'، مع وضعه بين علامتي اقتباس حتى لا يفسّر shell الأقواس. إذا لم تتمكن من تثبيت أي شيء بعد، فشغّل grep -rl crb /etc/yum.repos.d/، وافتح الملف الذي يحدده، واضبط enabled=1 يدوياً في القسم [crb].

ما الفرق بين CRB وPowerTools؟

إنهما المستودع نفسه تحت اسمين مختلفين. يسمّيه الإصدار 8 PowerTools، ومعرّفه powertools، بينما يسمّيه الإصدار 9 والإصدارات الأحدث CRB، ومعرّفه crb. وتسمّي Red Hat محتواه CodeReady Linux Builder. يوفّر هذا المستودع ترويسات التطوير، والمكتبات الساكنة، وأدوات وقت البناء، ويكون معطّلاً افتراضياً على Rocky وعلى AlmaLinux 9. يفعّله AlmaLinux 10 افتراضياً بدءاً من 10.0، لذلك تحقّق من dnf repolist --enabled قبل تشغيل أمر التفعيل هناك.

كيف أزيل EPEL مجدداً من دون التسبب في مشكلات؟

أنشئ جرداً أولاً باستخدام dnf repository-packages epel list installed، لأن إزالة الحزمة epel-release وحدها لا تزيل أي شيء ثُبّت من EPEL. تبقى تلك الحزم على القرص، وتفقد مصدر تحديثاتها، وتتوقف عن تلقي إصلاحات الأمان من دون ظهور خطأ يخبرك بذلك. قيّم الحزم واحدةً واحدة، وأزل أو استبدل ما لم تعد تحتاج إليه، ثم شغّل sudo dnf remove epel-release فقط. إذا كانت إحدى حزم EPEL لم تستبدل أي حزمة أخرى ويجب إزالتها، فإن sudo dnf repository-packages epel remove يزيل المجموعة في معاملة واحدة، لذلك اقرأ القائمة المقترحة بعناية قبل تأكيدها.