रिपॉ पैकेज या VPN क्लाइंट पैकेज: पहले कौन?

आप विक्रेता का पैकेज इंस्टॉल करते हैं, कमांड शून्य लौटाता है, और फिर भी शुरू करने के लिए कोई 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 बताना चाहिए, और उसके बाद शुरू न होना पैकेजिंग नहीं, ऐप की समस्या है।

रिपॉ के मालिक और ऐप पैकेज को अलग वस्तुओं के रूप में दर्ज करें, ताकि बाद में हटाना सही चीज़ ले और दूसरी अक्षुण्ण रहने दे। जब विक्रेता अपनी गाइड बदले, स्रोत प्रविष्टि वह है जिसे आप फिर पढ़ते हैं; क्लाइंट नाम वह है जिसे आप फिर इंस्टॉल करते हैं।