🖱️ 🆒 🕜 जेंटू में पर्ल मॉड्यूल स्थापित करना 🐌 🥢 🚣🏾

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

पसंद का धन ... या कोई अन्य TIMTOWTDI

इस समस्या के कई वैकल्पिक दृष्टिकोण हैं (और उनकी संख्या भी अप्रत्यक्ष रूप से इंगित करती है कि उनमें से कोई भी समस्या को अच्छी तरह से हल नहीं करता है): cpan , cpanplus , cpanminus , pip , cpansite , minicpan / mcpani , perlbrew , cpan- आउटडेटेड , cpan -सूची , स्थानीय :: परिवाद , ...

तो, हम कर सकते हैं:

पर्ल के कई संस्करण स्वयं (बेशक, प्रत्येक के अपने वैश्विक मॉड्यूल के साथ), सहित उपयोगकर्ता के होम डायरेक्टरी में स्थापित (देखें perlbrew)।
ग्लोबल (पर्ल की शुरुआत में सुलभ) और स्थानीय (किसी भी निर्देशिका / निर्देशिका से जुड़ा हुआ है, आमतौर पर एक अलग परियोजना के अंदर या उपयोगकर्ता के घर निर्देशिका में) मॉड्यूल।
तीन प्रकार के वैश्विक मॉड्यूल हैं: कोर (पर्ल के साथ आने वाला), साइट (प्रशासक द्वारा मैन्युअल रूप से स्थापित) और विक्रेता (आपके ओएस के पैकेज मैनेजर द्वारा स्थापित)।
सभी वैश्विक मॉड्यूल उपनिर्देशिका "version.perl.perl /" में स्थित हैं, और कोई भी इन निर्देशिकाओं को स्वचालित रूप से साफ नहीं करता है। और जब आप पर्ल के नए संस्करण को स्थापित करते हैं, तो नई समान निर्देशिकाएं बनाई जाती हैं। और सभी उपलब्ध पिछले संस्करणों की निर्देशिका से पर्ल लोड मॉड्यूल। तो perl अद्यतनों की संख्या से कोर + साइट + विक्रेता - कि आपके वैश्विक मॉड्यूल कितने निर्देशिका / विकल्प हैं।
मॉड्यूल के स्रोत भी अलग हैं: CPAN, स्थानीय CPAN ओवरले दर्पण निजी मॉड्यूल के साथ, बस आपके द्वारा या इंटरनेट मॉड्यूल से डाउनलोड किए गए CPAN- संगत सिस्टम में गायब हैं।

और इस सभी खुशी को प्रशासित किया जाना चाहिए: स्थापित करें, अपडेट करें ... ग्लोबल पेरल मॉड्यूल के प्रशासन को आसान बनाने के लिए जेंटू में जी-सेपन उपयोगिता है, और मैं इसके बारे में थोड़ी बात करना चाहता हूं।

काम करने का माहौल

शुरू करने के लिए, हम थोड़ा निर्दिष्ट करते हैं कि हमें किन परिस्थितियों में आमतौर पर काम करना है:

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

हमने पहले से ही CPAN- संगत स्थानीय दर्पण / ओवरले (देखें cpansite) से मॉड्यूल स्थापित करने और वैश्विक रूप से एक ही कॉपी में अधिकांश मॉड्यूल स्थापित करने के लिए खुद को सीमित करके हमारे जीवन को थोड़ा आसान बना दिया है। अगली समस्या: मॉड्यूल के लिए तीन वैश्विक स्थापना स्थानों के रूप में - कोर, साइट और विक्रेता । और इस वजह से, अक्सर टकराव पैदा होता है। Gentoo में वेंडर-साइट-कोर प्राथमिकता होती थी। इस वजह से, मैन्युअल रूप से cpan / cpanplus / etc. साइट में मॉड्यूल अक्सर उपलब्ध नहीं थे, क्योंकि विक्रेता का पुराना संस्करण था। और cpan जैसी उपयोगिताओं को बिना यह महसूस किए कि यह काम नहीं करता है, बिना मॉड्यूल को अपडेट कर सकता है। यह विक्रेता से सभी मॉड्यूल को हटाकर, और उन्हें /etc/portage/profile/package.provided में मैन्युअल रूप से लिखने के द्वारा हल किया गया था ताकि पोर्ट उन्हें फिर से स्थापित न करें (जिसके बाद सिस्टम अपडेट के दौरान सावधानीपूर्वक निगरानी करना आवश्यक था ताकि पोर्ट देव से पैकेज स्थापित न करें- perl / * या perl-core / *, और यदि आवश्यक हो, तो cpan के माध्यम से इन पैकेजों को स्थापित करें और उन्हें package.provided में पंजीकृत करें)। साइट-वेंडर-कोर अब प्राथमिकता है, लेकिन यह भी समस्या को पूरी तरह से हल नहीं करता है: कुछ (या शायद सभी, मैंने जांच नहीं की) कोर मॉड्यूल, जब cpan जैसी उपयोगिता से अपडेट किया जाता है, तो साइट में नहीं, बल्कि उन संस्करणों में शीर्ष पर स्थापित होते हैं। जो स्वयं पर्ल के साथ स्थापित हैं। यह दो अप्रत्याशित प्रभाव पैदा करता है: सबसे पहले, अगर इन कोर मॉड्यूल का एक और संस्करण (पर्ल-कोर / * पैकेज से) विक्रेता में स्थापित किया गया है, तो इसके अलावा cpan उपयोगिता के साथ मॉड्यूल के "अपडेट" के बावजूद, एक पुराना संस्करण विक्रेता; और दूसरी बात, देव-लैंग / पर्ल पैकेज को पुन: स्थापित करना (उदाहरण के लिए, रिडेप-रीबिल्ड के कारण) cpan के माध्यम से मैन्युअल रूप से इंस्टॉल किए गए सभी कोर मॉड्यूल अपडेट को रोल करता है।

जी cpan

उपरोक्त समस्याओं को देखते हुए, साथ ही “नियमित” साधनों जैसे कि cpan / cpanplus की असुविधा, हम आसानी से यह सुनिश्चित करने के लिए संपर्क कर रहे हैं कि सभी वैश्विक मॉड्यूल सिस्टम में अन्य सभी पैकेजों की तरह पोर्टिंग टूल को स्थापित, अपडेट और हटा दें। यदि हम साइट में मॉड्यूल की मैन्युअल स्थापना को पूरी तरह से छोड़ देते हैं, तो प्राथमिकता / ओवरलैपिंग मॉड्यूल / पुनः स्थापित करने वाली पर्ल की सभी समस्याओं का भी समाधान हो जाएगा। दुर्भाग्य से, पोर्टिंग में केवल CPAN मॉड्यूल के एक छोटे हिस्से के लिए पैकेज होते हैं, और निश्चित रूप से हमारे अपने निजी मॉड्यूल के लिए कोई पैकेज नहीं होते हैं। इस समस्या को हल करने के लिए, g-cpan उपयोगिता को विकसित किया गया था - यह किसी भी CPAN मॉड्यूल (CPAN- संगत दर्पण / ओवरले से निजी मॉड्यूल सहित) के लिए पैकेज उत्पन्न कर सकता है और उन्हें स्थानीय पोर्टेज ओवरले में सहेज सकता है, या बस उन्हें मक्खी पर स्थापित कर सकता है। जब मैंने कई साल पहले इसका उपयोग करने की कोशिश की, तो यह बहुत अच्छा नहीं था, और व्यावहारिक रूप से बेकार था। लेकिन अब यह पहले से ही पूरी तरह कार्यात्मक है - कम से कम मैं ~ 300 मॉड्यूल स्थापित करने में कामयाब रहा, और उनमें से केवल एक के लिए मुझे मैन्युअल रूप से पुनर्निर्माण करना था।

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

स्थापना और स्थापना

हम डालते हैं:
```
emerge g-cpan 
```
आपको एक उपरिशायी सेट करने की आवश्यकता है जहां जी-सेपन ईबिल्ड बनाएगा:
```
 echo "GCPAN_OVERLAY=/usr/local/portage" >> /etc/make.conf 
```
हम CPAN दर्पणों की अपनी सूची (हमारे स्थानीय दर्पण / पहले आइटम के रूप में ओवरले सहित) सेट करते हैं। सबसे आसान तरीका है कि पहले से ही कॉन्फ़िगर की गई सूची को cpan से कॉपी करना है:
```
 cpanmirrors=$(cpan -J | perl -0777 -ne 'eval;print"@{$CPAN::Config->{urllist}}"') echo "cpan $cpanmirrors" >> /etc/portage/mirrors 
```

चाहे स्थापना के दौरान मॉड्यूल का परीक्षण करना आवश्यक हो - हर एक अपने लिए निर्णय लेता है, लेकिन मैं परीक्षण चलाना पसंद करता हूं, खासकर मेरे मॉड्यूल के लिए। स्थापना के दौरान पर्ल मॉड्यूल के परीक्षण को तेज करने के लिए, आपको अपने हुक को पैकेज की संपूर्ण श्रेणियों में सेट करने की क्षमता जोड़ने की आवश्यकता है। निर्देशिका /etc/portage/bashrc.d/ बनाने के लिए संभावित तरीकों में से एक है और यह फ़ाइल / etc / portage / bashrc:

 # Useful variables and functions: # # EBUILD_PHASE= # clean # setup # unpack # compile # test # install # preinst # prerm # postrm # cleanrm # postinst # clean # # CATEGORY = app-admin # PF = eselect-opengl-1.0.6-r1 # P = eselect-opengl-1.0.6 # PN = eselect-opengl # PVR = 1.0.6-r1 # PV = 1.0.6 # PR = r1 (will be "r0" for packages without -r) # # einfo () # elog () # ewarn () # eerror () if [ "x${EBUILD_PHASE}" != "x" ]; then if [ -x "/etc/portage/bashrc.d/${CATEGORY}.${EBUILD_PHASE}" ]; then source "/etc/portage/bashrc.d/${CATEGORY}.${EBUILD_PHASE}" fi if [ -x "/etc/portage/bashrc.d/${CATEGORY}/${PF}.${EBUILD_PHASE}" ]; then source "/etc/portage/bashrc.d/${CATEGORY}/${PF}.${EBUILD_PHASE}" elif [ -x "/etc/portage/bashrc.d/${CATEGORY}/${P}.${EBUILD_PHASE}" ]; then source "/etc/portage/bashrc.d/${CATEGORY}/${P}.${EBUILD_PHASE}" elif [ -x "/etc/portage/bashrc.d/${CATEGORY}/${PN}.${EBUILD_PHASE}" ]; then source "/etc/portage/bashrc.d/${CATEGORY}/${PN}.${EBUILD_PHASE}" fi fi

जिसके बाद आप श्रेणियों के सभी संकुल perl-core / *, dev-perl / * और perl-gcpan / * में सक्षम कर सकते हैं:

 cat <<'EOF' >/etc/portage/bashrc.d/perl_module_test FEATURES="$FEATURES test" SRC_TEST="do" EOF cat <<'EOF' >/etc/portage/bashrc.d/perl_module_notest SRC_TEST= EOF chmod +x /etc/portage/bashrc.d/perl_module_* ln -s perl_module_test /etc/portage/bashrc.d/perl-core.test ln -s perl_module_test /etc/portage/bashrc.d/dev-perl.test ln -s perl_module_test /etc/portage/bashrc.d/perl-gcpan.test

और, यदि आवश्यक हो, तो कुछ मॉड्यूल के परीक्षण को अक्षम करें या किसी तरह इसे प्रभावित करें:

 mkdir /etc/portage/bashrc.d/dev-perl ln -s ../perl_module_notest /etc/portage/bashrc.d/dev-perl/Crypt-SSLeay.test ln -s ../perl_module_notest /etc/portage/bashrc.d/dev-perl/Shell-EnvImporter.test ln -s ../perl_module_notest /etc/portage/bashrc.d/dev-perl/Term-ReadLine-Perl.test cat <<'EOF' >/etc/portage/bashrc.d/dev-perl/Inline.test MAKEOPTS=-j1 EOF chmod +x /etc/portage/bashrc.d/dev-perl/Inline.test

इसके अलावा, आमतौर पर CPAN पर मॉड्यूल के नवीनतम संस्करण सबसे स्थिर होते हैं। यह हमारे निजी मॉड्यूल के मामले में और भी अधिक है। तो यह नवीनतम संस्करणों की स्थापना के लिए मजबूर करने के लिए समझ में आता है:
```
 cat <<'EOF' >>/etc/portage/package.keywords perl-core/* dev-perl/* virtual/perl-* # avoid depending on ~x86 sys-libs/readline dev-perl/Term-ReadLine-Gnu -~x86 # avoid depending on ~x86 sci-mathematics/pari dev-perl/math-pari -~x86 EOF 
```
अब हमें g-cpan के लिए CPAN इंडेक्स अपडेट करना होगा। सैद्धांतिक रूप से, g-cpan के पास इसके लिए thecpan_reload विकल्प है, लेकिन वर्तमान संस्करण (0.16.2) में यह काम नहीं करता है। और चूंकि जी-सेपन cpan यूटिलिटी इंडेक्स का उपयोग करता है, आप cpan चलाकर और cpan> पुनः लोड इंडेक्स करके इस समस्या के आसपास काम कर सकते हैं।
सर्वर पर सभी पर्ल स्क्रिप्ट द्वारा उपयोग किए जाने वाले मॉड्यूल की एक सूची तैयार करें। मैं बहु-मंजिला श-पाइपलाइनों के साथ प्रबंधित हुआ, लेकिन आपको शायद इसके लिए एक पर्ल स्क्रिप्ट लिखनी चाहिए और इसे इस लेख की टिप्पणियों में पोस्ट करना चाहिए। :)
हम उनके लिए ईबिल्ड उत्पन्न करते हैं (निर्भरता मॉड्यूल के लिए ईबर्ड भी स्वचालित रूप से बनाए जाएंगे):
```
 g-cpan -g Module::Name1 Module::Name2 … 
```
एक छोटा सा मौका है कि कुछ मॉड्यूल के लिए आपको /usr/local/portage/perl-gcpan/Module-Name/Module-Name-version.ebuild को पेन से एडिट करना होगा। (अब तक मैं केवल एक ही तरह से आया हूं: क्रिप्ट :: मैट्रिक्सएसएसएल।)
निर्देशिका / usr / lib / perl5 / site_perl / * हटाएं। चेतावनी , इस बिंदु पर, इस सर्वर पर अधिकांश पर्ल स्क्रिप्ट टूट जाएगी। दुर्भाग्य से, यदि विक्रेता मॉड्यूल स्थापित करने से पहले साइट मॉड्यूल को नहीं हटाया जाता है (जिसकी प्राथमिकता कम है), तो विक्रेता मॉड्यूल की स्थापना और परीक्षण के दौरान पहले से ही विक्रेता में स्थापित मॉड्यूल के साइट संस्करणों के उपयोग के कारण समस्याएं हो सकती हैं। हालांकि, समस्याएं आमतौर पर हल हो जाती हैं, इसलिए यदि आप कुछ समय के लिए "सिस्टम को तोड़ने" का जोखिम नहीं उठा सकते हैं, तो पहले विक्रेता मॉड्यूल स्थापित करें, लेकिन उसके बाद साइट मॉड्यूल के साथ निर्देशिका को हटाना न भूलें।
/Etc/portage/profile/package.provided से सभी पर्ल मॉड्यूल निकालें।
पहले हमने मॉड्यूल को आवश्यक पोर्टेज (यदि आपने पैकेज का उपयोग किया है। उन्नत और वे अब स्थापित नहीं हैं):
```
 emerge -uDNa @world 
```
और फिर जिन्हें आप की जरूरत है (यह समझ में आता है कि टेस्ट :: * मॉड्यूल पहले, फिर मैथ :: * - यह बाकी की स्थापना को गति देगा)। हम स्थापना के प्रयास को कई बार दोहराते हैं, जैसा कि नहीं सभी मॉड्यूल सही ढंग से निर्भरता जादू:
```
 until emerge -uDN --keep-going y \ Test-Deep Test-Differences Test-Distribution … \ Math-BigInt-GMP math-pari … \ … do read -p "Press <Enter> to try again" done 
```

अद्यतन

G-cpan उपयोगिता लॉन्च करने के लिए "cpan> अपग्रेड" का एक पूर्ण एनालॉग प्रदान नहीं करती है

 g-cpan -u

यह केवल उन मॉड्यूल्स को अपडेट करेगा जिनके लिए g-cpan ने पैकेज बनाए (यानी perl-gcpan / * श्रेणी से, और perl-core / * और dev-perl / * से पैकेज अपडेट नहीं होंगे)। लेकिन शायद यह इतना बुरा नहीं है - अंत में, इन मॉड्यूल को अपडेट करने के लिए, एक नियम के रूप में, प्रति-कोर / * या देव-पर्ल / * से / यूएसआर / स्थानीय / पोर्टेज में सिर्फ कॉपी और नाम बदलना। लेकिन मॉड्यूल के स्थापित संस्करणों और पिछले संस्करणों के लिए सुविधाजनक रोलबैक पर बेहतर नियंत्रण की संभावना है।

सारांश

मेरी राय में, g-cpan वास्तव में विश्व स्तर पर स्थापित पर्ल मॉड्यूल के प्रबंधन को सरल करता है। और विशाल 11-आइटम इंस्टॉलेशन सेक्शन के बावजूद, वास्तव में कुछ भी जटिल नहीं है (अच्छी तरह से, यह निर्धारित करने के अलावा कि आपको कौन से मॉड्यूल को स्थापित करने की आवश्यकता है :))।

सर्वरों की सफाई में गुड लक!