डिस्ट्रो नाम, glibc या कंपाइलर: इंस्टॉलर क्या जाँचता है

इंस्टॉलर “unsupported distribution” छापता है, आप एक स्ट्रिंग संपादित करते हैं और वह आगे बढ़ता है जब तक कि एक मिनट बाद लोडर त्रुटि के साथ विफल न हो जाए। वही क्रम वह लक्षण है जिसे पहचानना चाहिए: पहली विफलता पहचान जाँच थी और दूसरी संगतता की सीमा है। ये दो अलग समस्याएँ हैं जो संयोग से एक ही टर्मिनल में दिखती हैं। जाँच संपादित करके आप केवल पहली से दूसरी तक जा सकते हैं।

लक्षण: इंस्टॉलर आपके डेरिवेटिव पर रुक जाता है

जो स्क्रिप्ट डिस्ट्रिब्यूशन नाम पढ़ती है और आगे बढ़ने से इंकार करती है, वह आपको बता रही है कि उसके लेखक ने आपके डेरिवेटिव का परीक्षण नहीं किया। यह समर्थन का बयान है, तकनीकी तथ्य नहीं, और अक्सर इस अर्थ में गलत है कि पैकेज ठीक चलता।

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

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

तीन संस्करण जिन्हें लोग सिस्टम संस्करण कहते हैं

डिस्ट्रिब्यूशन रिलीज़ एक पैकेज्ड वातावरण का नाम देती है। C लाइब्रेरी संस्करण रनटाइम कार्यान्वयन और उसकी रिलीज़ का नाम देता है। कंपाइलर संस्करण टूलचेन का नाम देता है। बातचीत में लोग तीनों को “सिस्टम संस्करण” कहते हैं, और इंस्टॉलर में ये विनिमेय नहीं हैं।

cat /etc/os-release
ldd --version | head -1
gcc --version | head -1
uname -m

पहले से बना एप्लिकेशन उस रनटाइम की अपेक्षा करता है जो उसके लिंक होने के समय मौजूद था। होस्ट पर कंपाइलर बदलने से वह दोबारा लिंक नहीं होता, और नया टूलचेन उन लोडर प्रतीकों में कुछ नहीं बदलता जिनकी बाइनरी माँग करती है। आर्किटेक्चर फिर अलग से मायने रखता है, क्योंकि 64-बिट सिस्टम पर 32-बिट पैकेज ऐसे कारणों से विफल होता है जिन्हें कोई संस्करण स्ट्रिंग नहीं समझाती।

चारों आउटपुट रिपोर्ट के साथ रखें। इन्हें इकट्ठा करने में दस सेकंड लगते हैं और ये उन अधिकांश प्रश्नों का उत्तर देते हैं जो मेंटेनर अन्यथा आपसे ईमेल से पूछता।

त्रुटि पढ़ें, जाँच नहीं

पहली लॉन्च त्रुटि ही साक्ष्य है। अनुपस्थित साझा ऑब्जेक्ट के बारे में, या ऐसे प्रतीक संस्करण के बारे में संदेश जिसे लोडर पूरा नहीं कर सकता, रनटाइम निर्भरता की समस्या है। जो संदेश डिस्ट्रिब्यूशन नाम दोहराता है वह फिर पहचान जाँच है, किसी और जगह।

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

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

स्ट्रिंग संपादित करने से मदद क्यों नहीं मिलती

ऑपरेटिंग सिस्टम की पहचान को गलत ठहराना बदल देता है कि मशीन का हर प्रोग्राम खुद को कैसे देखता है। पैकेज मैनेजर, सहायता उपकरण और अन्य एप्लिकेशन वही फ़ाइल पढ़ते हैं, और एक इंस्टॉलर को संतुष्ट करने वाला मान महीनों बाद किसी और चीज़ को उलझा सकता है।

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

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

ऐसी रिपोर्ट लिखें जिस पर मेंटेनर कार्रवाई कर सके

डिस्ट्रिब्यूशन और रिलीज़, आर्किटेक्चर, VPN रिलीज़, अस्वीकार की गई सटीक शर्त और पहली रनटाइम त्रुटि दर्ज करें यदि आप वहाँ तक पहुँचे। लिखें कि आपने कुछ बदला या नहीं, क्योंकि बदले हुए सिस्टम से आई रिपोर्ट दूसरी रिपोर्ट होती है।

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

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