في Linux، كثيراً ما تفشل عملية التثبيت مع رسائل مثل “لا يمكن حل dependencies” أو “الحزمة المطلوبة غير متوفرة” أو “هناك تعارض مع حزمة أخرى”. وهذا لا يعني فقط أن برنامجاً واحداً لا يمكن تثبيته، بل غالباً ما يدل على أن حالة الحزم في النظام كله أصبحت غير متناسقة. إن مديري الحزم مثل apt وdnf وpacman يعملون على أساس أن libraries وruntimes والحزم المساعدة موجودة بتركيبات متوافقة من الإصدارات. وعندما تنكسر هذه السلسلة تتوقف عملية التثبيت.
المهم هنا ألا تُعامل dependency error على أنها مجرد مشكلة صغيرة من نوع “ينقصنا حزمة واحدة فقط”. ففي الواقع قد تكون الأسباب أعمق بكثير، مثل cache تالف، إعدادات repository قديمة، خلط مصادر من جهات خارجية، تحديثات توقفت في المنتصف، partial upgrade، حزم مقيّدة، libraries مثبّتة يدوياً، أو عدم تطابق architecture. لذلك لا ينبغي البدء بحذف الملفات عشوائياً أو تنزيل ملفات .deb / .rpm من مصادر غير موثوقة، بل يجب أولاً فهم أي dependency فشلت ولماذا.
ما المقصود بخطأ dependency؟
معظم الحزم في Linux لا تعمل بشكل مستقل. فقد يحتاج برنامج ما إلى library محددة، أو إصدار معيّن من runtime، أو أداة إضافية، أو مكوّن آخر من مكوّنات النظام. فإذا كان أحد هذه العناصر مفقوداً أو كان الإصدار غير مناسب، فإن مدير الحزم يوقف التثبيت حفاظاً على تماسك النظام.
لذلك، فإن dependency error لا تعني فقط أن “شيئاً ما مفقود”. بل قد تعني أيضاً أن شرطين لا يمكن تحقيقهما معاً، أو أن حزمتين تتعارضان، أو أن الإصدارات المتاحة لم تعد تكوّن مجموعة متناسقة.
الأعراض الشائعة
- ظهور رسائل تحتوي على
Depends:أوrequiresأوunresolved dependency - إبلاغ النظام بوجود حزم معطوبة أو dependencies غير قابلة للحل
- عند تثبيت حزمة، يطلب النظام إزالة حزم أخرى
- وجود library مطلوبة لكن الإصدار المناسب غير متوفر
- بعد تحديث ما، تبدأ عمليات التثبيت كلها بالفشل
- بدأت المشكلة بعد إضافة repository من جهة خارجية
- بعد partial upgrade أصبح النظام غير متناسق من ناحية الحزم
ما الذي يجب التحقق منه أولاً؟
أحياناً يبدو الأمر وكأنه مشكلة dependencies، بينما يكون السبب الحقيقي هو الشبكة أو DNS أو mirrors. لذلك يجب أولاً التأكد من أن الوصول إلى مصادر الحزم يعمل بشكل سليم.
ping -c 4 8.8.8.8
ping -c 4 google.com
ip addr
ip route
بعد ذلك، ينبغي التحقق مما إذا كان تحديث قوائم الحزم يتم بدون أخطاء.
sudo apt update
sudo dnf makecache
sudo pacman -Sy
إذا ظهرت هنا بالفعل أخطاء 404، أو مشاكل في name resolution، أو signature error، أو timeout، فقد لا يكون السبب الأساسي هو dependency نفسها.
الأسباب الرئيسية لأخطاء dependencies
1. خلط repositorys
هذا من أكثر الأسباب شيوعاً. فالمستودعات الرسمية، وPPA القديمة، والمصادر الخاصة بإصدارات مختلفة من التوزيعة، ومستودعات الاختبار، والمصادر الخارجية، قد تقدم الحزمة نفسها لكن بإصدارات وقواعد dependencies مختلفة. وبهذا قد تصبح لديك حزمة تحتاج إلى library أحدث، وأخرى لا تعمل إلا مع إصدار أقدم، ولا يمكن تحقيق الاثنين معاً.
2. تحديث متوقف في المنتصف
إذا توقفت عملية التحديث بسبب انقطاع الكهرباء، أو إغلاق الطرفية، أو انقطاع SSH، أو تجمد الواجهة الرسومية، فقد تبقى بعض الحزم محدّثة وبعضها الآخر قديماً. وهذه الحالة الجزئية تُعد سبباً شائعاً جداً في ظهور dependency errors.
3. Partial upgrade
تشتهر هذه المشكلة خصوصاً في Arch Linux، حيث إن partial upgrade غير موصى به بشدة. لكن حتى في Debian / Ubuntu أو Fedora، فإن فرض تحديث بعض الحزم الأساسية دون تحديث بقية النظام قد يؤدي إلى النوع نفسه من عدم الاتساق.
4. الحزم المقيّدة أو المثبّتة على إصدار ثابت
إذا كانت بعض الحزم مقيّدة على إصدار قديم، فقد لا تتمكن الحزم الأخرى من الانتقال إلى الإصدار الذي تحتاجه. عندها تنسد سلسلة dependencies كلها.
5. التثبيت اليدوي خارج مدير الحزم
تثبيت libraries يدوياً، أو نسخ الملفات مباشرة إلى النظام، أو استخدام حزم منفصلة بلا إدارة مصادر سليمة، قد يجعل الحالة الفعلية للنظام مختلفة عما يعتقده مدير الحزم.
6. الحزم المتعارضة
ليس كل dependency error يعني أن شيئاً ما مفقود. أحياناً تكون المشكلة الحقيقية أن حزمتين لا يمكن أن تتواجدا معاً، إما لأنهما توفران الملف نفسه أو لأنهما مصممتان بحيث تستبعد إحداهما الأخرى.
7. عدم تطابق architecture
قد تكون الحزمة المطلوبة موجودة فعلاً، ولكن ليس للبنية الصحيحة. فخلط 32-bit و64-bit بشكل غير سليم، أو محاولة تثبيت حزمة لبنية أخرى، قد يظهر أيضاً على شكل dependency error.
8. Cache أو metadata غير متناسقة
قد تمنع قوائم الحزم القديمة، أو cache التالف، أو metadata غير المتزامنة مع mirrors، مدير الحزم من رؤية dependency موجودة فعلاً في repository.
ما الذي يجب فحصه في أنظمة apt
في Debian / Ubuntu يجب النظر ليس فقط إلى apt بل أيضاً إلى حالة dpkg.
إصلاح الحالات غير المكتملة
sudo dpkg --configure -a
sudo apt --fix-broken install
بعد تحديث متوقف في المنتصف، تكون هاتان الخطوتان غالباً أفضل بداية.
فحص الحزم المقيّدة
apt-mark showhold
الحزمة المقيّدة قد تمنع سلسلة dependencies كلها من التقدم.
فحص الإصدارات والمصادر
apt-cache policy اسم-الحزمة
بهذا يمكن معرفة الإصدارات المتاحة والمصدر الذي تأتي منه.
ما الذي يجب فحصه في أنظمة dnf
في Fedora / RHEL يجب التركيز على سلامة حالة النظام وسجل المعاملات.
فحص الحالة الحالية
sudo dnf check
يساعد هذا في اكتشاف dependencies غير المحققة على مستوى النظام كله.
إعادة المزامنة مع حالة التوزيعة
sudo dnf distro-sync
إذا كانت بعض الحزم متقدمة وبعضها متأخر، فغالباً ما يساعد هذا في إعادة النظام إلى حالة متناسقة.
عرض الشروط غير المحققة
sudo dnf repoquery --unsatisfied
وهذا يوضح بشكل أفضل أي dependencies لم يتم تحقيقها.
ما الذي يجب فحصه في أنظمة pacman
في Arch Linux من الضروري استعادة الاتساق الكامل للنظام وتجنب partial upgrade.
تحديث النظام بالكامل
sudo pacman -Syu
إذا كانت dependency error موجودة بالفعل، فإن محاولة حل المشكلة بتحديث بعض الحزم فقط تؤدي غالباً إلى تفاقمها.
تحديث قاعدة المزامنة
sudo pacman -Syy
وهذا مهم عندما لا تعود المعلومات المحلية مطابقة لما في mirrors.
السجلات مهمة جداً
نادراً ما يمكن فهم dependency error من السطر الأخير فقط. يجب معرفة أي حزمة تطلب أي إصدار، وأي مرشح تم رفضه، ولماذا.
apt / dpkg
sudo tail -n 100 /var/log/apt/history.log
sudo tail -n 100 /var/log/dpkg.log
dnf
sudo journalctl -xe --no-pager | tail -n 100
sudo dnf history
pacman
sudo tail -n 100 /var/log/pacman.log
ترتيب عملي للتشخيص
الخطوة 1: فحص الشبكة والوصول إلى repositorys
ping -c 4 8.8.8.8
ping -c 4 google.com
الخطوة 2: تحديث قوائم الحزم
sudo apt update
sudo dnf makecache
sudo pacman -Syy
الخطوة 3: إصلاح الحالات غير المكتملة
في apt باستخدام dpkg --configure -a، وفي dnf باستخدام dnf check، وفي pacman باتباع نهج المزامنة الكاملة.
الخطوة 4: فحص الإصدارات والمصادر الخاصة بالحزمة المشكلة
يجب معرفة من أين تأتي الحزمة، وما الإصدارات المتاحة، وهل هناك إصدار مقيّد.
الخطوة 5: الاشتباه في repositorys الخارجية والإعدادات القديمة
العديد من dependency errors تنشأ في الحقيقة من خلط خاطئ للمصادر.
ما الذي يجب تجنبه
- تثبيت حزم إضافية عشوائياً من دون فهم الخطأ
- تنزيل ملفات .deb / .rpm من مواقع غير موثوقة
- الاستمرار في partial upgrade
- إيقاف التحقق من التوقيع أو dependencies
- إضافة المزيد من repositorys الخارجية دون معرفة السبب الحقيقي
كيف تتجنب تكرار المشكلة
- اعتمد على repositorys الرسمية قدر الإمكان
- لا تُبقِ PPA قديمة أو مصادر خاطئة
- لا تقطع التحديثات في المنتصف
- تجنب partial upgrade في Arch
- أنشئ snapshot أو backup قبل التغييرات الكبيرة
الخلاصة
عندما يفشل التثبيت في Linux بسبب dependency errors، فالمشكلة غالباً أعمق من مجرد library واحدة مفقودة. فخلط repositorys، والتحديثات المتوقفة، والpartial upgrade، والحزم المقيّدة، والتثبيت اليدوي، وتعارضات architecture كلها أسباب شائعة. المفتاح هو قراءة الخطأ بعناية وفهم أي حزمة تطلب أي إصدار ولماذا لا يستطيع النظام توفيره. وبعد ذلك فقط يتم استخدام الطريقة الصحيحة: dpkg --configure -a وapt --fix-broken install في apt، وdnf check وdistro-sync في dnf، والمزامنة الكاملة مع التحديث الكامل في pacman.