आवृत्ती स्ट्रिंग VPN प्लगइनचे वैशिष्ट्य सिद्ध करत नाही

तीन प्रश्न आवृत्तीच्या युक्तिवादाला वैशिष्ट्याच्या तपासणीपासून वेगळे करतात: पर्याय कोणत्या घटकाने पुरवायचा, त्या घटकाची कोणती आवृत्ती प्रत्यक्षात स्थापित आहे, आणि त्याबद्दल त्याचा बदल नोंद काय सांगतो। प्लगइनचा क्रमांक एकटाच यापैकी कोणालाही उत्तर देत नाही। मोहक शॉर्टकट, संक्षिप्त आवृत्तीची ट्युटोरियलमधील किमानशी तुलना करणे, अयशस्वी होते कारण वितरणांच्या आवृत्ती स्ट्रिंग दशांश नसतात। तुलना करण्यापूर्वी तुम्ही काय तुलना करत आहात ते ठरवा।

पर्याय NetworkManager मध्ये, त्याच्या VPN प्लगइनमध्ये, खालील इंजिनमध्ये, किंवा वेगळ्या डेस्कटॉप फ्रंटएंडमध्ये राहू शकतो। ते चार प्रकल्प आहेत, चार रिलीझ इतिहासांसह।

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

तुम्ही पाहत असलेला संपादक सहसा प्लगइन असतो, आणि प्लगइन OpenVPN बायनरी किंवा WireGuard अंमलबजावणीसारख्या इंजिनला कॉल करतो। NetworkManager स्वतः कनेक्शन मॉडेल देतो, आणि डेस्कटॉप फ्रंटएंड त्यावर स्वतःची फील्ड्स जोडू शकतो। वैशिष्ट्य त्यापैकी कोणत्याही ठिकाणी दिसू शकते, आणि एकाचे अपग्रेड केल्याने इतर अपग्रेड होत नाहीत। नवीन इंजिन हे स्थापित संपादक इंजिनला समर्थित पर्याय आयात करू शकतो याचा पुरावा नाही।

लक्षणापासून सुरुवात करा: फील्ड संवादातून गायब आहे, आयातीनंतर अनुपस्थित आहे, की आहे पण दुर्लक्षित आहे? ती निरीक्षणे वेगवेगळ्या घटकांकडे निर्देश करतात आणि वेगवेगळे पुरावे मागतात।

तुलना करण्यापूर्वी आवृत्तीचे विश्लेषण करा

Debian ची पॅकेज धोरण स्वरूपाला epoch, upstream आवृत्ती आणि पॅकेजिंग revision असे परिभाषित करते। प्रथम epoch, नंतर upstream भाग, नंतर revision ची तुलना केली जाते, पॅकेज व्यवस्थापकाच्या स्वतःच्या क्रमवारी नियमांनुसार, दशांश अंकगणित किंवा साध्या वर्णक्रमानुसार नाही। टिल्डा सर्वांपूर्वी क्रमवारीत येते, त्या भागाच्या शेवटासह, आणि अशा प्रकारे रिलीझ उमेदवार अंतिम रिलीझच्या आधी येतो। भाग वेगळे वाचणे हेच तुलनेला अर्थपूर्ण बनवते।

0.8.999 हे 0.9 जवळ दिसणाऱ्या इतर कोणत्याही योजनेसाठी रूपांतरण नियम तयार करू नका। अंकांची जवळीक हा सामग्रीबद्दलचा पुरावा नाही।

काय स्थापित आहे आणि काय असेल ते विचारा

apt-cache policy तुम्ही नामांकित केलेल्या प्रत्येक पॅकेजसाठी स्थापित आवृत्ती, उमेदवार आणि प्रत्येकजण कोणत्या रेपॉझिटरीतून येतो ते नोंदवते। इंजिन आणि प्लगइन दोन्हींसाठी ते वाचा, आणि संक्षिप्त रूपांऐवजी पूर्ण स्ट्रिंग नोंदवा। स्थानिक मेटाडेटा जुना असू शकतो, आणि उमेदवार आवृत्ती हे सिद्ध करत नाही की चालू प्रक्रियेने ती बिल्ड लोड केली आहे। अपग्रेडनंतर सेवा पुन्हा सुरू केली नसल्यास, डिस्कवरील फाइल आणि तुम्ही पाहत असलेले वर्तन वेगळे असू शकते।

नंतर जुळणारा बदल नोंद वाचा। पॅकेजिंग revision नवीन upstream क्रमांक स्वीकारल्याशिवाय पॅचेस घेऊन जाऊ शकते, आणि आवृत्ती अपरिवर्तित दिसते पण वर्तन वेगळे असते तो नेमका तोच प्रसंग।

पर्याय मालक घटकात सिद्ध करा

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

त्या रिलीझसाठीच्या समर्थित बिल्डमध्ये एकात्मता नसल्यास, मंजूर अपडेट मार्ग किंवा दुसरा क्लायंट निवडा। दुसऱ्या रिलीझची रेपॉझिटरी मिसळणे, किंवा दिसणारा क्रमांक वाढवण्यासाठी संग्रहित स्रोत पॅच लागू करणे, आवृत्तीचा युक्तिवाद असमर्थित प्रणालीशी बदलते।

उपयुक्त अहवाल वितरण, पूर्ण पॅकेज आवृत्त्या, सक्रिय कनेक्शनचा मालक, आवश्यक पर्याय आणि निरीक्षित जतन केलेले वर्तन यांची नोंद करतो। हा पुनरुत्पादनयोग्य प्रश्न आहे।