‏DNF يعمل عبر الوسيط. فلماذا لا يعمل GNOME Software؟

ينزّل DNF الحزم دون أي شكوى. يعرض GNOME Software الفهرس، ثم يتوقف عندما تطلب تثبيت شيء. من المغري أن نستنتج أن التطبيق الرسومي يتجاهل الوسائط ببساطة. لكن هناك احتمال آخر: معلومات الوسيط لم تصل قط إلى المكوّن الذي ينفّذ التنزيل.

تتبّع عملية التسليم

لا يملك GNOME Software والأمر الذي أدخلته في الطرفية مسار الإعداد نفسه. تصف وثائق وسيط PackageKit عمليةً تابعة للجلسة تقرأ إعدادات سطح المكتب وتمرّرها إلى الخدمة الخلفية. في GNOME، يقرأ gnome-software إعدادات GSettings ويستدعي واجهة إعداد الوسيط في PackageKit.

ثم توفّر الخدمة الخلفية إعدادات الجلسة المناسبة للواجهة الخلفية الخاصة بالحزم. وهذا يعني أن طلب DNF الناجح يثبت أن الوسيط قادر على خدمة ذلك الاستدعاء من DNF. لكنه لا يثبت أن جلسة سطح المكتب سجّلت الإعدادات نفسها لدى PackageKit.

ثلاثة أسئلة مفيدة

1. أي عملية فشلت؟ عرض بيانات الفهرس وتحديث البيانات الوصفية وتنزيل حزمة عمليات مختلفة. سجّل العملية التي تُنتج الخطأ فعلاً.
2. هل سُجّل وسيط الجلسة؟ افحص إعدادات الوسيط الفعلية على سطح المكتب وأخطاء PackageKit المبلّغ عنها. فشل تعيين الوسيط يختلف عن وسيط يعيد 407 أثناء التنزيل.
3. أي إصدار يملك الإعداد؟ تغيّرت PackageKit بمرور الوقت. مفتاح إعداد منسوخ من إجابة عن Fedora 25 قد يصف خلفية قديمة أو خطأً لم يعد ينطبق.

متغيّرات الطرفية المصدَّرة ليست بديلاً موثوقاً لفحص عملية التسليم هذه. فالخدمة الخلفية ليست ابنة الصدفة التي كتبت فيها export، وقد يكون لولوج رسومي بيئة مختلفة.

أبقِ أي إصلاح مرتبطاً بالمكوّن المسؤول عن المشكلة. إن كان إعداد سطح المكتب خاطئاً، فصحّح ذلك الإعداد. وإن فشل التسجيل، فاحفظ خطأه ومعلومات إصداره. وإن رفض الوسيط التنزيل، فافحص سياسة المصادقة أو الوجهة لديه. وتحرير كل ملفات المستودعات دفعةً واحدة قد يطمس الفرق ويجعل إعدادات سطر الأوامر والإعدادات الرسومية أصعب في الصيانة.