तपाईं विक्रेताको प्याकेज स्थापना गर्नुहुन्छ, आदेश शून्य फर्काउँछ, र अझै सुरु गर्ने VPN अनुप्रयोग छैन। यो तब हुन्छ जब तपाईंले स्थापना गरेको प्याकेजले क्लाइन्ट दिनुको सट्टा रेपो कन्फिगर गर्यो, र फरक यसले डिस्कमा के छोड्यो भन्नेमा देखिन्छ। दुवै आवश्यक छ कि छैन र कुन क्रममा, यो विक्रेताको नाममा होइन, तीन सर्तमा निर्भर गर्दछ। तलको निर्णयले स्रोत सेटअप, मेटाडाटा रिफ्रेस र अनुप्रयोग स्थापनालाई अलग प्रमाणसहित अलग कार्यका रूपमा राख्छ।

प्रत्येक प्याकेजले वास्तवमा के बदल्छ

रेपो कन्फिगरेसन प्याकेजले APT स्रोत प्रविष्टि लेख्छ, त्यो प्रविष्टिले विश्वास गर्ने हस्ताक्षर कुञ्जी आयात गर्छ, र बाहिरिन्छ। यसको सामग्री /etc/apt मुनिका केही फाइल र एउटा कुञ्जी औंठी हो, र चलाउन केही छैन। क्लाइन्ट प्याकेजले डिमन वा डेस्कटप अनुप्रयोग, त्यसका पुस्तकालय र निर्भरताहरू दिन्छ, र मेनु वा systemd इकाईमा पुग्ने वस्तु त्यही हो।

-release मा अन्त्य हुने फाइल नामहरूले पहिलो प्रकार संकेत गर्छन्, तर प्रत्यय परम्परा हो, ग्यारेन्टी होइन। प्याकेजको भूमिकाबारे विश्वसनीय भनाई त्यसको फाइल सूची र निर्भरताहरू हुन्, र दुवै केही पनि स्थापना गर्नुअघि पढ्न सकिन्छ। आफ्नो प्याकेजिङ पुनः आकार दिने विक्रेताले त्यही फाइल नाम राख्छ र सामग्री बदल्छ, त्यसैले दुई वर्ष पुरानो थ्रेडबाट प्रतिलिपि गरिएको उत्तर अब नभएको प्याकेज वर्णन गर्न सक्छ। तपाईंले चलाउनुभएको रिलिजका लागि प्रदायकका हालका निर्देशन पढ्नुहोस्, त्यसपछि प्याकेजले के घोषणा गर्छ जाँच्नुहोस्।

त्यो विभाजनबाट तीन चरण आउँछन्: स्रोत दर्ता गर्नुहोस्, त्यसले पोषण गर्ने मेटाडाटा रिफ्रेस गर्नुहोस्, त्यसपछि अनुप्रयोग नामले स्थापना गर्नुहोस्। Debian र Ubuntu स्थापना गाइड ले तिनलाई अलग राख्छ, त्यसैले क्लाइन्ट स्रोत सेट गर्ने प्याकेजबाट होइन, पछिको चरणमा मागिन्छ।

क्रम निर्धारण गर्ने तीन सर्त

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

दोस्रो हो, तपाईंको वितरणमा क्लाइन्ट पहिले नै छ कि छैन। भएमा, वितरण प्याकेजले तपाईंको रिलिजको पुस्तकालय संक्रमण र सुरक्षा अद्यावधिक अनुसरण गर्छ, जबकि विक्रेता प्याकेज छिटो चल्न सक्छ र साझा पुस्तकालयका आफ्नै प्रतिलिपि ल्याउन सक्छ।

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

स्रोत लाइन अस्तित्वमा आउनुअघि ती तीन उत्तर तय गर्नुहोस्, किनकि पछि हटाउनु भनेको प्याकेज र त्यसको कुञ्जी सफा गर्नु हो। तय भएपछि, विक्रेता मार्गभित्रको क्रम विकल्प होइन: पहिले स्रोत, दोस्रो मेटाडाटा, तेस्रो अनुप्रयोग, कहिल्यै उल्टो होइन।

रिलिज प्याकेजले के छोड्यो जाँच्नुहोस्

अरू केही स्थापना गर्नुअघि विवरण होइन, फाइल सूची पढ्नुहोस्। Debian परिवारका प्रणालीमा प्याकेज म्यानिफेस्टले के कन्फिगर गर्यो र कुञ्जी कहाँ पुग्यो भन्ने जवाफ दिन्छ।

dpkg -L proton-vpn-release | grep -E 'apt|keyring'
apt-cache policy proton-vpn-gnome-desktop
grep -r protonvpn /etc/apt/sources.list.d/

पहिलो पङ्क्तिले स्रोत फाइल र कुञ्जी औंठीको मार्ग देखाउँछ, दोस्रो पङ्क्तिले कन्फिगर गरिएका स्रोतले कुन संस्करण दिन सक्छन् भनी जनाउँछ। यदि apt-cache policy ले क्लाइन्ट नामका लागि केही छाप्दैन भने, मेटाडाटा रिफ्रेस भएको छैन वा स्रोतले अर्को सूट लक्ष्य गरेको छ। तेस्रोले प्रविष्टि APT ले वास्तवमा पढ्ने ठाउँमा छ भनी पुष्टि गर्छ।

कुञ्जी औंठीको मार्गलाई स्रोत लाइनको signed-by= फिल्डसँग मिलाउनुहोस्। गलत डाइरेक्टरीमा रहेको कुञ्जीले अप्रमाणित स्रोतको त्रुटि उत्पन्न गर्छ, जुन उपलब्ध नभएको प्याकेजभन्दा फरक खराबी हो।

निर्भरता विफलतालाई अलग चरण मान्नुहोस्

डाउनलोड गरिएको .deb लाई dpkg -i सँग स्थापना गर्नुले केही समाधान गर्दैन: यसले निर्भरता जाँच्छ, के छुटेको छ जनाउँछ र प्याकेजलाई आधा कन्फिगर गरिएको छोड्छ। त्यो अपेक्षित व्यवहार हो, बिग्रिएको डाउनलोड होइन।

त्यसपछि apt --fix-broken install ले तपाईंका स्रोतबाट APT लाई सुसंगत अवस्था माग्छ। APT लाई तपाईं कुन VPN चाहनुहुन्थ्यो थाहा छैन, र यसको योजनाले भेटिएको बाधा पूरा गर्न प्याकेज हटाउन सक्छ। हो भन्नुअघि प्रस्तावित कारोबार पढ्नुहोस्, र हटाइले तपाईंलाई चाहिने कुरा छोयो भने रोक्नुहोस्। योजना नपढी मर्मत दोहोर्याउनु भनेको सानो निर्भरता अन्तरलाई फेरि नखुल्ने डेस्कटप बनाउने तरिका हो।

प्याकेज म्यानेजरको पहिलो अर्थपूर्ण सन्देश सुरक्षित राख्नुहोस् र कार्य गर्नुअघि वर्गीकरण गर्नुहोस्। हस्ताक्षर नगरिएको रेपो, कन्फिगर गरिएका स्रोतमा नभएको प्याकेज, संस्करण द्वन्द्व, र खुल्ने अनि मर्ने क्लाइन्ट चार फरक खराबी हुन्।

अनुप्रयोग प्रमाणित गर्नुहोस्, रेपो होइन

क्लाइन्ट स्थापित अवस्थामा पुगेको पुष्टि गर्नुहोस्, त्यसपछि कार्यक्रम खुल्ने पुष्टि गर्नुहोस्। dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop ले संस्करणसहित install ok installed जनाउनुपर्छ, र त्यसपछिको सुरु नहुनु प्याकेजिङको होइन, अनुप्रयोगको समस्या हो।

रेपोको मालिक र अनुप्रयोग प्याकेजलाई अलग वस्तुका रूपमा अभिलेख गर्नुहोस्, ताकि पछिको हटाइले सही कुरा लैजाओस् र अर्को अक्षत रहोस्। विक्रेताले आफ्नो गाइड बदल्दा, स्रोत प्रविष्टि त्यो हो जो तपाईं फेरि पढ्नुहुन्छ; क्लाइन्ट नाम त्यो हो जो तपाईं फेरि स्थापना गर्नुहुन्छ।

सम्बन्धित लेखहरू