डेबियन फिर से कई आरंभीकरण प्रणालियों का समर्थन करेगा

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

दुर्घटना के कारण के रूप में, systemd पैकेज के साथ टकराव और libsystemd को बदलने का खतरा था लिबेलोगिंड के वैकल्पिक संस्करण के साथ, जो एबीआई स्तर पर स्रोत लाइब्रेरी के साथ पूरी तरह से असंगत है।

इलोगिंड का समावेश लिबेलोगिंड लाइब्रेरी का अपना संस्करण प्रदान करता है, जो libsystemd द्वारा प्रस्तावित कई कार्यों को अपने हाथ में ले लेता है और इंस्टालेशन के दौरान इस लाइब्रेरी को बदल देता है।

पैकेज में, elogind को systemd लाइब्रेरीज़ के साथ विरोधाभासी के रूप में चिह्नित किया गया है, लेकिन यह स्वाभाविक रूप से केवल systemd के बिना काम करने के लिए डिज़ाइन किया गया है और systemd के साथ विरोध और भी फायदेमंद है, क्योंकि यह आपको गलती से elogind इंस्टॉल नहीं करने देता है।

दूसरी ओर, वर्तमान स्वरूप में, APT के माध्यम से सिस्टमडी कॉन्फिगरेशन को sysvinit और elogind वाले संस्करण में अपडेट करने के प्रयासों के परिणामस्वरूप सिस्टम में भ्रष्टाचार होता है एक निष्क्रिय एपीटी के साथ। लेकिन इस दोष को दूर करने के बाद भी, पहले से स्थापित उपयोगकर्ता वातावरण को हटाए बिना सिस्टमडी से ईलॉगिंड में संक्रमण अभी भी असंभव है।

जिसके बाद Elogind डेवलपर्स को Elogin को अनुकूलित करने के लिए कहा गयाd अपनी स्वयं की libpam-elogind परत का उपयोग किए बिना, नियमित libpam-systemd के शीर्ष पर काम करने के लिए।

सेक्टरों की अवधारणा के लिए समर्थन की कमी के कारण elogind से libpam-systemd में संक्रमण बाधित होता है, लेकिन elogind डेवलपर्स पूर्ण एपीआई अनुपालन प्राप्त नहीं करना चाहते हैं और सभी सिस्टमड सुविधाओं को सटीक रूप से दोहराना नहीं चाहते हैं, क्योंकि elogind केवल उपयोगकर्ता लॉगिन को व्यवस्थित करने के लिए न्यूनतम कार्यक्षमता प्रदान करता है। और इसका उद्देश्य सिस्टमडी के सभी उपप्रणालियों को दोहराना नहीं है।

वर्णित तकनीकी मुद्दों का समाधान रिलीज़ टीम और elogind और systemd के अनुरक्षकों के बीच बातचीत के स्तर पर हल किया जाना चाहिए, लेकिन प्रोजेक्ट लीडर को हस्तक्षेप करने के लिए मजबूर होना पड़ा क्योंकि टीमें सहमत नहीं हो सकीं, संयुक्त कार्य टकराव में बदल गया, और समस्या का समाधान एक गतिरोध पर पहुंच गया, जिसमें कानून का प्रत्येक पक्ष अपने तरीके से।

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

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

वर्तमान में, रिपॉजिटरी में पहले से ही 1033 पैकेज जमा हो चुके हैं जो सिस्टमडी के लिए सेवा इकाइयाँ प्रदान करते हैं, लेकिन इसमें init.d स्क्रिप्ट शामिल नहीं हैं।

इस समस्या को हल करने के लिए, डिफ़ॉल्ट रूप से सेवा फ़ाइलों की आपूर्ति करने का प्रस्ताव है, लेकिन एक ड्राइवर तैयार करने का प्रस्ताव है जो स्वचालित रूप से इन फ़ाइलों से कमांड को पार्स करेगा और उनके आधार पर init.d स्क्रिप्ट उत्पन्न करेगा।

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

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

सिस्टमडी से लिंक करना यह परिवर्तन को भी काफी जटिल बना देगा भविष्य में वितरण विकास की दिशा में और सेवा आरंभीकरण और प्रबंधन के क्षेत्र में आगे के प्रयोगों को सीमित करेगा।

प्रत्येक समाधान के अपने फायदे और नुकसान हैं, इसलिए वोट से पहले पक्ष और विपक्ष में सभी तर्कों पर गहन चर्चा की आवश्यकता होगी।

Fuente: https://lists.debian.org/