NPP: हम क्या देंगे

राष्ट्रीय सॉफ़्टवेयर प्लेटफ़ॉर्म के लिए प्रोटोटाइप सिस्टम प्रोजेक्ट पर ROSA की R & D टीम द्वारा टिप्पणी।

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

हमने रूस में इस परियोजना को पैकेज रिअसाव के दौरान स्वचालित निर्भरता मिलान के हमारे दीर्घकालिक विचार को लागू करने के लिए शुरू किया था। अर्थात्, एबीएफ इस तरह से काम करता है कि नए पैकेज विफल नहीं होते हैं (और रिपॉजिटरी में समाप्त नहीं होते हैं) जब तक कि सभी निर्भरताएं वापस नहीं हो जाती हैं। सहमत पुनर्निर्माण प्रक्रिया सहित अनुमति देता है अंगूठी निर्भरता संभाल। नतीजतन, एक बार संकुल के एक समूह की विधानसभा की शुद्धता और पुनरुत्पादकता (और इसलिए वितरण और उनके लिए कोई भी कार्यक्रम) प्राप्त किए जाते हैं, तो वे रखरखावकर्ताओं की लापरवाह कार्रवाइयों द्वारा आगे उल्लंघन नहीं करते हैं (जो कि ABF के विचारकों को फेडोरा के डेरिवेटिव का निर्माण करते समय, और बाद में अपने पिछले जीवन में निपटना पड़ा था। Mandriva के लिए)। यदि अनुरक्षक एक कम-गुणवत्ता वाला पैकेज प्रदान करता है, तो वह तुरंत और इसे पुनः प्राप्त करने के निर्देश के साथ स्वचालित रूप से वापस प्राप्त करेगा।

ROSA / Mandriva के सिस्टम आर्किटेक्ट्स के अनुसार, वितरण के निर्माण के दौरान निरंतर एकीकरण, ताज़गी की बदलती डिग्री के पैकेज से दैनिक असेंबलियों का तथ्य नहीं है, जैसा कि अक्सर होता है, लेकिन बहुत अधिक हद तक - बिल्ड मैनेजर के विश्वास कि छवि में सभी पैकेज इकट्ठे होते हैं एक दूसरे के साथ संघर्ष के बिना, और आपको इसे पूरी तरह से जांचने की ज़रूरत है, न कि स्थानीय रूप से लागू परीक्षणों का एक सेट। यह हमें अजीब लगता है कि अन्य पैकेजों के असेंबली पैकेज का उल्लंघन दुर्घटना से काफी हद तक पता चलता है, मैन्युअल रूप से और पुनर्निर्माण के अनुरोधों को मैन्युअल रूप से किसी भी प्रतिक्रिया की गारंटी के बिना मेलिंग सूची में रखा जाता है। यह आखिरी सदी है।

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

मैं दोहराता हूं, हम लंबे समय से आरओएस पर कल्पना की गई और विकसित की गई तकनीकों के बारे में बात कर रहे हैं, और शुरू में आंतरिक जरूरतों के लिए विकसित की गई हैं। हमने इन तकनीकों को सौंपने का प्रयास नहीं किया है, हमने विशेष रूप से प्रतियोगिता के लिए तैयार नहीं किया है (और प्रोटोटाइप तैयार करने की प्रक्रिया में हमें तत्काल कुछ आवश्यकताओं के लिए कोड को अनुकूलित करना होगा), इसके अलावा, पेंगुइन के आवेदन का बजट इन तकनीकों को विकसित करने के लिए पहले से ही हमारे स्वयं के खर्चों को भी कवर नहीं करेगा। फिर भी, यदि हम इस अनुबंध में तकनीकी विकल्पों का प्रश्न उठाते हैं, तो हम अपनी प्रौद्योगिकियों को भागीदारी के योग्य मानते हैं और, महत्वपूर्ण रूप से, काफी आधुनिक (ऊपर देखें)। हम जिस स्तर के लिए आवेदन कर रहे हैं वह लॉन्चपैड और ओबीएस स्तर है।

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

एवगेनी सोकोलोव
रोसा आर एंड डी