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 टाइप गर्नुभएको शेलको सन्तान होइन, र ग्राफिकल लगइनको वातावरण फरक हुन सक्छ।

कुनै पनि सुधार समस्याको मालिक कम्पोनेन्टसँग जोडिएर राख्नुहोस्। डेस्कटप कन्फिगरेसन गलत छ भने त्यही कन्फिगरेसन सुधार्नुहोस्। दर्ता असफल भए त्यसको त्रुटि र संस्करण जानकारी सुरक्षित राख्नुहोस्। प्रोक्सीले डाउनलोड अस्वीकार गरे त्यसको प्रमाणीकरण वा गन्तव्य नीति अन्वेषण गर्नुहोस्। सबै रिपोजिटरी फाइल एकैचोटि सम्पादन गर्दा भिन्नता धमिलिन सक्छ र कमाण्ड-लाइन तथा ग्राफिकल कन्फिगरेसन मर्मत गर्न कठिन हुन्छ।