डेबियन बहु प्रारम्भिक प्रणालीहरूको लागि समर्थनमा फर्कन्छ

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

याद elogind systemd स्थापना नगरी GNOME चलाउन आवश्यक इन्टरफेसहरू प्रदान गर्दछ। यो परियोजना systemd-logind को एक फोर्क को रूप मा स्थापित भएको थियो, एक अलग प्याकेज मा राखिएको र systemd कम्पोनेन्टहरु को बाध्यता देखि मुक्त। अन्य चीजहरू मध्ये, elogind ले libelogind पुस्तकालयको आफ्नै संस्करण प्रदान गर्दछ, जसले libsystemd मा प्रस्तावित धेरै प्रकार्यहरू लिन्छ र स्थापनाको समयमा यो पुस्तकालयलाई प्रतिस्थापन गर्दछ।

ब्लक गर्नुका कारणहरू systemd प्याकेजसँग द्वन्द्व र libsystemd लाई वैकल्पिक libelogind ले प्रतिस्थापन गर्ने खतरा थियो, जुन ABI स्तरमा स्रोत पुस्तकालयसँग पूर्णतया असंगत छ।
प्याकेजले elogind लाई systemd पुस्तकालयहरूसँग विरोधाभासको रूपमा लेबल गर्दछ, तर यो स्वाभाविक रूपमा systemd बिना मात्र काम गर्न डिजाइन गरिएको हो, र systemd सँग द्वन्द्व वास्तवमा लाभदायक हुन्छ किनभने यसले गल्तीद्वारा elogind स्थापना हुनबाट रोक्छ। अर्कोतर्फ, यसको हालको ढाँचामा, APT मार्फत sysvinit र elogind को साथ संस्करणमा कन्फिगरेसन अपडेट गर्न को लागी प्रयास क्षतिग्रस्त प्रणाली APT काम गर्दैन। तर यदि यो कमजोरी हटाइयो भने पनि, systemd बाट elogind मा संक्रमण पहिले नै स्थापित प्रयोगकर्ता वातावरण मेटाउन असम्भव रहन्छ।

Elogind विकासकर्ताहरू थिए प्रस्तावित आफ्नै libpam-elogind तह प्रयोग नगरी मानक libpam-systemd को शीर्षमा काम गर्न elogind अनुकूलन गर्नुहोस्। elogind लाई libpam-systemd मा ट्रान्जिसन स्लाइस को अवधारणा को लागी समर्थन को कमी को कारण बाधित छ, तर elogind को विकासकर्ताहरु API को साथ पूर्ण अनुपालन प्राप्त गर्न चाहँदैनन् र systemd को सबै क्षमताहरु लाई दोहोर्याउन चाहँदैनन्, किनकि elogind ले न्यूनतम प्रदान गर्दछ। प्रयोगकर्ता लगइनहरू व्यवस्थित गर्नका लागि कार्यक्षमता र सबै प्रणालीगत उपप्रणालीहरू नक्कल गर्ने लक्ष्य राख्दैन।

वर्णन गरिएका प्राविधिक समस्याहरूको समाधान रिलिज टोली र इलोगिन्ड र प्रणालीगत रखरखावकर्ताहरू बीचको अन्तरक्रियाको स्तरमा समाधान गरिनु पर्छ, तर टोलीहरू सहमत हुन नसकेका कारण परियोजना नेता हस्तक्षेप गर्न बाध्य भए, संयुक्त कार्य टकरावमा विकसित भयो र समाधानको लागि। समस्या अन्त्यमा पुग्यो, जसमा प्रत्येक पक्ष आफ्नै तरिकामा सही थियो। सैम हार्टम्यानका अनुसार, अवस्था सामान्य भोट (GR, सामान्य संकल्प) को आवश्यकता पर्ने राज्यमा आइपुगेको छ, जसमा समुदायले elogind सँग sysvinit को लागि init र समर्थनको लागि वैकल्पिक प्रणालीको बारेमा निर्णय गर्नेछ।

यदि परियोजना सदस्यहरूले init प्रणाली विविधीकरण गर्न मतदान गरे भने, सबै मर्मतकर्ताहरू यस समस्याको समाधान गर्न सँगै काम गर्न संलग्न हुनेछन् वा विशिष्ट विकासकर्ताहरूलाई यस मुद्दामा काम गर्न नियुक्त गरिनेछ र रखरखावकर्ताहरूले अब वैकल्पिक इनिट प्रणालीलाई बेवास्ता गर्न, मौन बस्न, वा प्रक्रिया ढिलाइ।

हाल भण्डारमा पहिले नै छ संचित 1033 प्याकेजहरू जसले systemd का लागि सेवा एकाइहरू प्रदान गर्दछ, तर init.d लिपिहरू समावेश गर्दैन। यो समस्या समाधान गर्न प्रस्ताव गरिएको पूर्वनिर्धारित रूपमा सेवा फाइलहरू आपूर्ति गर्नुहोस्, तर एक ह्यान्डलर तयार गर्नुहोस् जसले स्वचालित रूपमा यी फाइलहरूबाट आदेशहरू पार्स गर्नेछ र तिनीहरूमा आधारित init.d लिपिहरू उत्पन्न गर्नेछ।

यदि समुदायले निर्णय गर्छ कि डेबियनसँग एकल init प्रणालीको लागि पर्याप्त समर्थन छ, हामी अब sysvinit र elogind को बारेमा चिन्ता गर्न सक्दैनौं र केवल एकाइ फाइलहरू र systemd मा फोकस गर्न सक्दैनौं। यो निर्णयले लिनक्स कर्नेल प्रयोग नगर्ने पोर्टहरूलाई नकारात्मक प्रभाव पार्नेछ (डेबियन GNU / हर्ड, डेबियन GNU / नेटबीएसडी и डेबियन GNU / kFreeBSD), तर मुख्य अभिलेखमा त्यस्ता कुनै पोर्टहरू छैनन् र तिनीहरूको स्थिति छैन आधिकारिक रूपमा समर्थित.

Systemd मा बन्धनले भविष्यमा वितरणको दिशा परिवर्तन गर्न अझ गाह्रो बनाउनेछ र प्रारम्भिकरण र सेवा व्यवस्थापनको क्षेत्रमा थप प्रयोगहरूलाई सीमित गर्नेछ। elogind लाई मेटाउने र फेरि थप्ने प्रयास गर्नु भन्दा काम गर्ने फारममा कायम राख्न धेरै सजिलो छ। प्रत्येक निर्णय विकल्पमा फाइदा र बेफाइदा हुन्छ, त्यसैले मतदान गर्नु अघि सबै पक्ष र विपक्षहरूको पूर्ण छलफल आवश्यक हुनेछ।

स्रोत: opennet.ru