URL-आधारित प्याकेज डाउनलोडका लागि RPM प्रोक्सी विकल्पहरू
जब प्रत्यक्ष दूरस्थ प्याकेज आदेश DNF भन्दा फरक व्यवहार गर्छ, तब RPM का आफ्नै URL-फेच प्रोक्सी विकल्पहरू जाँच्नुहोस्।
rpm -Uvh https://packages.example.net/example.rpm मा नेटवर्कबाट फेच गर्ने चरण समावेश छ। प्याकेज प्रमाणित वा स्थापना गर्नु अघि RPM ले फाइल प्राप्त गर्नुपर्छ।
कार्यरत DNF प्रोक्सी कन्फिगरेसनले त्यो छुट्टै कलले प्रयोग गर्ने सेटिङहरू निर्धारण गर्दैन। RPM को म्यानुअलले यसको HTTP पुनःप्राप्ति मार्गका लागि --httpproxy र --httpport कागजात गर्छ। स्थापित RPM संस्करण र यसको URL सहायकको व्यवस्थाले विवरण निर्धारण गर्छ। RPM 6 को सामान्य-विकल्प सन्दर्भले यी नेटवर्क-फेच विकल्पहरूलाई अप्रचलित भनी चिन्ह लगाउँछ र यसको सट्टा curl वा GNU Wget जस्ता समर्पित फेच उपकरण सिफारिस गर्छ।
तपाईंले मर्मत गरिरहनुभएको कार्यप्रवाहका लागि पहिले कुन तहले URL फेच गर्छ भनी निर्धारण गर्नुहोस्। नयाँ कार्यप्रवाहका लागि स्पष्ट रूपमा स्वीकृत डाउनलोड र त्यसपछि स्थानीय प्याकेज प्रमाणीकरण र स्थापनाले यी अप्रचलित फेच विकल्पहरूमा निर्भरता टार्छ।
फिल्डहरूलाई तिनीहरूको कागजात गरिएको ढाँचामा राख्नुहोस्। प्रोक्सी होस्टनाम मागिएको जहाँसुकै प्रत्येक संस्करणले प्रमाण-पत्रसहितको URL स्वीकार्छ भनी नमान्नुहोस्, र पुरानो उत्तरले त्यसो गरेको भरमा कुनै वितरणको ग्लोबल म्याक्रो फाइल सम्पादन नगर्नुहोस्।
असफलताको चरण पहिचान गर्नुहोस्: फेच प्रोक्सीसम्म पुग्न सक्यो, प्रमाणीकरण स्वीकार भयो, र प्याकेजको अन्त्य बिन्दुले इच्छित फाइल फर्कायो? पछि आउने हस्ताक्षर वा निर्भरता त्रुटि अड्किएको प्रोक्सी जडानभन्दा फरक समस्या हो।
सामान्य प्याकेज प्रमाणीकरण कायम राख्नुहोस्। डाउनलोड मार्ग कार्यरत बनाउनु हस्ताक्षर जाँच बन्द गर्न, अविश्वसनीय फाइल स्थापना गर्न वा सफल DNF आदेशलाई यो RPM फेचले उही मार्ग लियो भन्ने प्रमाण मान्ने कारण होइन।