डेबियन मल्टिपल इनिट सिस्टीमसाठी समर्थनासाठी परत येतो

सॅम हार्टमन, डेबियन प्रोजेक्ट लीडर, प्रयत्न केला वितरणाचा भाग म्हणून elogind पॅकेजच्या वितरणाशी संबंधित मतभेद समजून घेण्यासाठी. जुलै मध्ये, प्रकाशन तयार करण्यासाठी जबाबदार संघ अवरोधित चाचणी शाखेत elogind चा समावेश करणे, कारण हे पॅकेज libsystemd शी विरोधाभास आहे.

की आठवण्याचा elogind systemd इंस्टॉल न करता GNOME चालवण्यासाठी आवश्यक इंटरफेस पुरवतो. प्रकल्पाची स्थापना systemd-logind चा एक काटा म्हणून केली गेली होती, एका वेगळ्या पॅकेजमध्ये ठेवली गेली होती आणि systemd घटकांच्या बंधनापासून मुक्त होते. इतर गोष्टींबरोबरच, elogind libelogind लायब्ररीची स्वतःची आवृत्ती प्रदान करते, जी libsystemd मध्ये ऑफर केलेली अनेक फंक्शन्स घेते आणि स्थापनेदरम्यान या लायब्ररीची जागा घेते.

अवरोधित करण्याचे कारण म्हणजे systemd पॅकेजसह संघर्ष आणि libsystemd ला पर्यायी libelogind ने बदलण्याचा धोका होता, जो ABI स्तरावरील स्त्रोत लायब्ररीशी पूर्णपणे विसंगत आहे.
संकुल elogind ला systemd लायब्ररीशी विरोधाभासी म्हणून लेबल करते, परंतु हे मूळतः systemd शिवाय कार्य करण्यासाठी डिझाइन केलेले आहे, आणि systemd सह विरोधाभास करणे खरोखर फायदेशीर आहे कारण ते चुकून elogind स्थापित होण्यापासून प्रतिबंधित करते. दुसरीकडे, सध्याच्या फॉर्ममध्ये, एपीटी द्वारे कॉन्फिगरेशनला सिस्विनिट आणि इलोगिंडसह सिस्टिम्ड वरून आवृत्तीमध्ये अपडेट करण्याचा प्रयत्न केल्याने खराब झालेली प्रणाली एपीटी काम करत नाही. परंतु जरी ही कमतरता दूर केली गेली तरी, आधीच स्थापित केलेले वापरकर्ता वातावरण हटविल्याशिवाय systemd ते elogind मधील संक्रमण अशक्य आहे.

Elogind विकासक होते प्रस्तावित स्वतःचा libpam-elogind लेयर न वापरता, मानक libpam-systemd वर काम करण्यासाठी elogind चे रुपांतर करा. elogind चे libpam-systemd मधील संक्रमण स्लाइसच्या संकल्पनेला समर्थन नसल्यामुळे बाधित होते, परंतु elogind चे विकासक API चे पूर्ण पालन करू इच्छित नाहीत आणि systemd च्या सर्व क्षमतांची पुनरावृत्ती करू इच्छित नाहीत, कारण elogind फक्त किमान प्रदान करते वापरकर्ता लॉगिन आयोजित करण्यासाठी कार्यक्षमता आणि सर्व सिस्टम्ड उपप्रणाली प्रतिकृती बनविण्याचे उद्दिष्ट नाही.

वर्णन केलेल्या तांत्रिक समस्यांचे निराकरण रिलीझ टीम आणि एलोगिंड आणि सिस्टमड मेंटेनर्स यांच्यातील परस्परसंवादाच्या पातळीवर केले जावे, परंतु प्रकल्प लीडरला हस्तक्षेप करण्यास भाग पाडले गेले कारण संघ सहमत होऊ शकले नाहीत, संयुक्त कार्य संघर्षात विकसित झाले आणि समस्येचे निराकरण झाले. समस्या अंतिम टप्प्यात पोहोचली, ज्यामध्ये प्रत्येक बाजू आपापल्या मार्गाने योग्य होती. सॅम हार्टमनच्या मते, परिस्थिती सामान्य मताची (जीआर, सामान्य ठराव) आवश्यकता असलेल्या राज्याच्या जवळ येत आहे, ज्यामध्ये समुदाय इनिटसाठी पर्यायी प्रणाली आणि एलोगिंडसह सिव्हिनिटसाठी समर्थन ठरवेल.

जर प्रकल्प सदस्यांनी init प्रणालीमध्ये विविधता आणण्यासाठी मतदान केले, तर सर्व देखभालकर्ता या समस्येचे निराकरण करण्यासाठी एकत्र काम करण्यात गुंतले जातील किंवा विशिष्ट विकासकांना या समस्येवर काम करण्यासाठी नियुक्त केले जाईल आणि देखभालकर्ता यापुढे पर्यायी init प्रणालीकडे दुर्लक्ष करू शकणार नाहीत, शांत राहतील किंवा प्रक्रियेस विलंब.

सध्या भांडारात आधीच आहे जमा 1033 पॅकेजेस जे systemd साठी सेवा युनिट पुरवतात, परंतु init.d स्क्रिप्ट समाविष्ट करत नाहीत. या समस्येचे निराकरण करण्यासाठी देऊ केले पूर्वनिर्धारितपणे सेवा फाइल्सचा पुरवठा करा, परंतु एक हँडलर तयार करा जो या फाइल्समधील कमांड्स आपोआप पार्स करेल आणि त्यावर आधारित init.d स्क्रिप्ट तयार करेल.

डेबियनला सिंगल इनिट सिस्टीमसाठी पुरेसा सपोर्ट आहे असे जर समुदायाने ठरवले, तर आम्ही यापुढे sysvinit आणि elogind बद्दल काळजी करू शकत नाही आणि फक्त युनिट फाइल्स आणि systemd वर लक्ष केंद्रित करू शकतो. हा निर्णय लिनक्स कर्नल वापरत नसलेल्या पोर्टवर नकारात्मक परिणाम करेल (डेबियन जीएनयू / हर्ड, डेबियन जीएनयू / नेटबीएसडी и डेबियन जीएनयू / केफ्रीबीएसडी), परंतु अद्याप मुख्य संग्रहणात असे कोणतेही पोर्ट नाहीत आणि त्यांची स्थिती नाही अधिकृतपणे समर्थित.

systemd ला बंधनकारक केल्याने भविष्यात वितरणाची दिशा बदलणे अधिक कठीण होईल आणि आरंभ आणि सेवा व्यवस्थापन क्षेत्रात पुढील प्रयोग मर्यादित होतील. इलोगिंड हे हटवण्यापेक्षा आणि नंतर पुन्हा जोडण्याचा प्रयत्न करण्यापेक्षा कार्यरत स्वरूपात राखणे खूप सोपे आहे. प्रत्येक निर्णय पर्यायामध्ये साधक आणि बाधक असतात, म्हणून मतदान करण्यापूर्वी सर्व साधक आणि बाधकांची संपूर्ण चर्चा आवश्यक असेल.

स्त्रोत: opennet.ru