बैसाखी या सरप्राइज पाईज़ तैनात करें

खोदना या नहीं खोदना?

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

इसलिए, प्रोग्रामर ने प्रोग्राम बनाया और इसे वितरित करना चाहता है, अब एक कार्य है - उपयोगकर्ता द्वारा प्रोग्राम इंस्टॉल करना। इसके लिए, ऐसा लगता है कि मानक (एफएचएस, एलएसबी) हैं, हालांकि, सॉफ्टवेयर इंस्टॉलेशन टूल्स की विविधता बस हतोत्साहित करने वाली है और प्रोग्रामर, अपनी क्षमता के सर्वश्रेष्ठ, इंस्टॉलेशन टूल को सरल README से कुछ और अधिक जटिल है।
हां, आज अधिकांश वितरणों में प्रोग्राम इंस्टॉल करने की एक प्रणाली है, जो वितरण किट के भीतर प्रोग्राम इंस्टॉल करने के मुद्दों को हल करता है और कुछ हद तक प्रोग्रामर के काम को सुविधाजनक बनाता है। और जब विभिन्न वितरणों (डेटा केंद्रों, वीएम में रैक) के एक बड़े समूह को प्रबंधित करने के लिए आवश्यक था, तो विभिन्न कॉन्फ़िगरेशन मैनेजमेंट सिस्टम (CFEngine, Bcfg2 कठपुतली, बावर्ची, आदि) बनाए गए थे। और सब कुछ ठीक लग रहा है, लेकिन पिछले 14 वर्षों से (जब रेडहैट लिनक्स 5.2 ने पिक करना शुरू किया था), इस सभी विविधता की बैसाखी की भावना ने मुझे नहीं छोड़ा ... तो क्या बात है?

जड़ें

मैं उन सभी सतहीकरणों को छोड़ने की कोशिश करूंगा जो आज एक विशिष्ट लिनक्स वितरण में प्रोग्राम को स्थापित / अनइंस्टॉल करने के लिए उपयोग किए जाते हैं - मुझे यह पता लगाना होगा कि प्रोग्राम को हटाने के लिए हेलोवर्ल्ड से अधिक कठिन क्या करना है:

• विन्यास प्रबंधन प्रणाली;
• पैकेज प्रबंधक;
• बिना किसी अपवाद के, सभी इंस्टॉलेशन स्क्रिप्ट, जिनमें प्रारंभिक क्रियाएं होती हैं जैसे कि लाइब्रेरी, संसाधन, प्रोग्राम प्रलेखन, संकलन स्क्रिप्ट आदि रखने के लिए निर्देशिका बनाना;
• और यहां तक ​​कि एक README / INSTALL फ़ाइल।

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

और इसके बारे में क्या करना है?

एक सरल इंस्टॉल प्रोग्राम है जो आपको कॉपी की जाने वाली फ़ाइलों के लिए आवश्यक विशेषताओं को कॉपी और सेट करने की अनुमति देता है, हालांकि, इसके काम के परिणामों को सामान्य आरएम के साथ हटा दिया जाना चाहिए।
किसी भी प्रोग्राम को चलाने और उसके निष्पादन को पूरा करने के लिए, फ़ाइल खोलने और उसे खोलने के लिए निष्पादित () और _exit () फ़ंक्शन उपलब्ध हैं और खुले () / बनाने () और बंद () फ़ंक्शन हैं। उसी समय, जब प्रोग्राम को निष्पादित / रोकते हैं, तो एक प्रक्रिया पहचानकर्ता ( पीआईडी ) होती है, और जब एक फ़ाइल को खोलना / बंद करना होता है - एक फ़ाइल विवरणक। तो क्यों न किसी प्रोग्राम को इंस्टॉल / अनइंस्टॉल करने के लिए प्रोग्राम प्लेसमेंट आइडेंटिफायर जैसा कुछ स्थापित किया जाए, मान लें कि यह डिप्लॉय आईडी ( DID ) / इंस्टाल आईडी ( IID ) है, जो वास्तव में एक मानक UUID हो सकता है, जो संचालन के लिए कई कार्य प्रदान करता है उदाहरण के लिए _appinstall () / _appupdate () / _appuninstall () / etc और टाइप ps के संबंधित कमांड के इस पहचानकर्ता, उदाहरण के लिए ऐप? और इसके घटकों के साथ कार्यक्रम की मेजबानी क्यों नहीं करते हैं, चलो कहते हैं कि अंदर नहीं

/etc/program.conf /etc/program.conf.d/someone.conf /usr/bin/program /usr/lib/program/libprogram.so /usr/share/doc/program/manual.txt /var/program/database 

और में

  /etc/<did>/program.conf /etc/<did>/program.conf.d/someone.conf /usr/bin/<did>/program /usr/lib/<did>/libprogram.so /usr/docs/<did>/manual.txt /var/<did>/database 

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

सूखी पटाखे या एक मछली पकड़ने वाली छड़ी फेंक?

सामान्य तौर पर, ऐसे वितरण होते हैं जो अपने घटकों और कॉन्फ़िगरेशन फ़ाइलों, जैसे कि GoboLinux (जो विकास को रोकते हैं) के कार्यक्रमों के प्लेसमेंट को एकीकृत करने की दिशा में आगे बढ़े हुए प्रतीत होते हैं, और मेरी राय में, इस दृष्टिकोण के सबसे करीब निक्स प्रबंधक और इसके आधार पर निक्सोस वितरण है। लेकिन मुझे लगता है कि हमें एफएचएस के लिए बड़े पैमाने पर पहल, चर्चा की आवश्यकता है। जब तक मैं सही हूं।

ये पिस रहे हैं।

_{PS किसी तरह मैंने इस विषय पर 2006 में gentoo.ru फोरम पर एक चर्चा की ।}

UPD : तुरंत माइनस करें, सवाल पूछें:
एक प्रोग्रामर सूट, कह सकते हैं, प्रक्रिया के कांटे के तरीके में अंतर की उपस्थिति, डेबियन और रेडहैट में कह सकते हैं? मुझे लगता है कि (मंच का दिमाग नहीं)। तो कार्यक्रम स्थापित करने के लिए विभिन्न नियमों और दृष्टिकोणों के रूप में बैसाखी क्यों है?

UPD : जैसा कि आप LOR पर टिप्पणियों से देख सकते हैं, स्टीरियोटाइप से निपटने में असमर्थता हार्ड-दबाए गए विंडोज़ उपयोगकर्ताओं के लिए अद्वितीय नहीं है, अफसोस, मैं कुछ स्पष्टीकरण जोड़ूंगा :
यह योजना सरल तर्क द्वारा प्रतिष्ठित है - पहले से स्थापित और मानकीकृत आधार फ़ाइल पदानुक्रम (निक्स के विपरीत, जिसमें परिवर्तन अत्यधिक कुल हैं, उदाहरण के लिए / usr / बिन / env -> के बिना सिस्टम में तैनात एक पैकेज उदाहरण के लिए एक आईडी)। / nix / store / id-coreutils-version / bin / env, यह इस तथ्य के बावजूद कि पीएम निक्स स्वयं आपको मुख्य प्रणाली को प्रभावित किए बिना $ घर के साथ किसी भी वितरण में अपने कूड़ेदान को व्यवस्थित करने की अनुमति देता है)।

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

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

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