वर्ज़न स्ट्रिंग VPN प्लगइन की सुविधा साबित नहीं करती

तीन सवाल वर्ज़न की दलील को सुविधा की जाँच से अलग करते हैं: कौन-सा घटक विकल्प देने वाला है, उस घटक का कौन-सा वर्ज़न वास्तव में इंस्टॉल है, और उसका चेंजलॉग इसके बारे में क्या कहता है। प्लगइन का नंबर अकेले इनमें से किसी का जवाब नहीं देता। लुभावना शॉर्टकट, किसी छोटे किए गए वर्ज़न की तुलना किसी ट्यूटोरियल के न्यूनतम से करना, इसलिए विफल होता है क्योंकि डिस्ट्रिब्यूशन वर्ज़न स्ट्रिंग दशमलव नहीं होतीं। तुलना करने से पहले तय करें कि आप क्या तुलना कर रहे हैं।

विकल्प NetworkManager में, उसके VPN प्लगइन में, नीचे के इंजन में, या अलग डेस्कटॉप फ्रंटएंड में रह सकता है। ये चार प्रोजेक्ट हैं, चार रिलीज़ इतिहास के साथ।

चार घटक, चार रिलीज़ इतिहास

जो एडिटर आप देखते हैं वह आमतौर पर प्लगइन होता है, और प्लगइन OpenVPN बाइनरी या WireGuard कार्यान्वयन जैसे इंजन को बुलाता है। NetworkManager खुद कनेक्शन मॉडल देता है, और डेस्कटॉप फ्रंटएंड उसके ऊपर अपने फ़ील्ड जोड़ सकता है। सुविधा इनमें से किसी में भी दिख सकती है, और एक को अपग्रेड करने से बाकी अपग्रेड नहीं होते। नया इंजन इस बात का सबूत नहीं है कि इंस्टॉल किया गया एडिटर उस विकल्प को आयात कर सकता है जिसे इंजन समर्थित करता है।

लक्षण से शुरू करें: फ़ील्ड डायलॉग से गायब है, आयात के बाद अनुपस्थित है, या मौजूद है पर अनदेखा किया जाता है? वे अवलोकन अलग-अलग घटकों की ओर इशारा करते हैं और अलग-अलग सबूत माँगते हैं।

तुलना से पहले वर्ज़न का विश्लेषण करें

Debian की पैकेज नीति प्रारूप को epoch, upstream वर्ज़न और पैकेजिंग revision के रूप में परिभाषित करती है। पहले epoch की तुलना होती है, फिर upstream भाग की, फिर revision की, पैकेज मैनेजर के अपने क्रम नियमों से, न कि दशमलव अंकगणित या साधारण वर्णानुक्रम से। टिल्डा सबसे पहले क्रमबद्ध होता है, उस भाग के अंत सहित, और इसी तरह रिलीज़ उम्मीदवार अंतिम रिलीज़ से पहले आता है। भागों को अलग-अलग पढ़ना ही तुलना को अर्थपूर्ण बनाता है।

किसी और योजना के लिए रूपांतरण नियम न गढ़ें जिसमें 0.8.999, 0.9 के करीब दिखता है। अंकों की निकटता सामग्री के बारे में सबूत नहीं है।

पूछें कि क्या इंस्टॉल है और क्या होगा

apt-cache policy आपके द्वारा नामित हर पैकेज के लिए इंस्टॉल किया गया वर्ज़न, उम्मीदवार और वह रिपॉज़िटरी बताता है जिससे हर एक आता है। इसे इंजन और प्लगइन दोनों के लिए पढ़ें, और संक्षिप्त रूपों की जगह पूरी स्ट्रिंग दर्ज करें। स्थानीय मेटाडेटा पुराना हो सकता है, और उम्मीदवार वर्ज़न यह साबित नहीं करता कि चल रही प्रक्रिया ने वह बिल्ड लोड किया है। यदि अपग्रेड के बाद किसी सेवा को पुनः आरंभ नहीं किया गया, तो डिस्क पर फ़ाइल और आप जो व्यवहार देखते हैं, वे भिन्न हो सकते हैं।

फिर मेल खाता चेंजलॉग पढ़ें। पैकेजिंग revision नया upstream नंबर अपनाए बिना पैच ले जा सकता है, और ठीक वही स्थिति है जहाँ वर्ज़न अपरिवर्तित दिखता है और व्यवहार अलग होता है।

विकल्प को उसके स्वामी घटक में साबित करें

आयात समस्या के लिए केवल डायलॉग नहीं, बल्कि इंस्टॉल किए गए प्लगइन के समर्थित फ़ील्ड और सहेजे गए परिणाम की जाँच करें। लेबल, मूल डेटा फ़ील्ड और इंजन आर्ग्युमेंट एक ही सेटिंग के तीन रूप हो सकते हैं, और फ़ाइल आयात करने की सफलता यह नहीं बताती कि हर निर्देश बचा रहा। सुविधा का सटीक नाम दें: उदाहरण के लिए, इस निर्देश को उसका प्रमाणीकरण-अर्थ बनाए रखते हुए स्वीकार करना।

यदि उस रिलीज़ का समर्थित बिल्ड एकीकरण नहीं रखता, तो स्वीकृत अपडेट पथ या कोई दूसरा क्लाइंट चुनें। किसी अन्य रिलीज़ की रिपॉज़िटरी मिलाना, या दिखने वाला नंबर बढ़ाने के लिए संग्रहित स्रोत पैच लगाना, वर्ज़न की दलील को असहाय सिस्टम से बदल देता है।

उपयोगी रिपोर्ट डिस्ट्रिब्यूशन, पूर्ण पैकेज वर्ज़न, सक्रिय कनेक्शन का स्वामी, आवश्यक विकल्प और देखे गए सहेजे गए व्यवहार का नाम लेती है। यह पुनरुत्पाद्य सवाल है।