आर्क लिनक्स पर Devtools का उपयोग करना

• Devtools का उपयोग कर संकलन
• Devtools कॉन्फ़िगरेशन फ़ाइलें
• स्थानीय रिपोजिटरी
• पैकेज तेजी से

पैकेज देवटूल मूल रूप से विश्वसनीय उपयोगकर्ताओं के लिए आधिकारिक रिपॉजिटरी के लिए पैकेज बनाने के लिए बनाया गया था। हालाँकि, इसका उपयोग सामान्य उपयोगकर्ता और साथ ही AUR पैकेज या संशोधित आधिकारिक पैकेज बनाने के लिए भी कर सकते हैं।

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

Devtools में स्थित एक अलग स्वच्छ आर्क इंस्टॉलेशन को बनाए रखता है /var/lib/archbuild/<TARGET>/root, जिसमें केवल पैकेज समूह होते हैं baseऔर base-devel। यदि यह साफ स्थापना मौजूद नहीं है, तो यह स्वचालित रूप से इसे बनाता है। यदि यह मौजूद है, तो यह स्वचालित रूप से इसमें किसी भी पैकेज को अपडेट करता है। जब Devtools का उपयोग पैकेज बनाने के लिए किया जाता है, तो यह इस क्लीन इंस्टॉलेशन की एक कॉपी से शुरू होता है, आवश्यक पैकेज को कॉपी में स्थापित करता है, सोर्स कोड को कॉपी करता है, इसमें कंपाइलिंग और पैकेजिंग करता है, और केवल परिणामी पैकेज को कॉपी करता है, आधिकारिक रिपॉजिटरी में जो पाया जाता है उससे समान रूप में।

makepkgसीधे दौड़ने से देवटूलों को फायदे हैं। एक लाभ यह है कि base-develसंकलन करने के लिए आवश्यक अन्य पैकेज हैं, लेकिन नहीं चलाने के लिए, जो पैकेज आप बना रहे हैं, वह आपके मुख्य सिस्टम में कभी हवा नहीं है। यह समय-समय पर अपग्रेड करने के लिए कम पैकेज है, और इसे लेकर चिंताएं हैं। हालाँकि मुख्य रूप से आर्क पैकेज मेंटेनर्स के लिए एक लाभ है, लेकिन PKGBUILDगलत होने पर यह प्रक्रिया आसानी से समाप्त हो जाती है, जैसे कि अगर कोई निर्भरता सूचीबद्ध होने से चूक जाती है कि अनुरक्षक अपने मुख्य सिस्टम में पहले ही स्थापित हो जाता है। आप एक ऐसी मशीन का भी उपयोग कर सकते हैं जो पैकेज बनाने में तेज है, और परिणामस्वरूप पैकेज को एक धीमी मशीन पर कॉपी करें जो इसे चलाएगी, बिल्डिंग मशीन की स्थापना को प्रदूषित किए बिना।

मुख्य नुकसान यह है कि स्वच्छ जड़ हमेशा होती है, लगभग 800 एमबी ले रही है, और आमतौर पर एक भी प्रतिलिपि अधिक जगह ले रही है। ध्यान दें, यदि /var/lib/archbuild/Btrfs का उपयोग किया जाता है , तो क्लीन रूट की प्रतिलिपि Btrfs स्नैपशॉट होना शुरू हो जाती है, इसलिए वे फाइलें डबल स्पेस नहीं लेती हैं। हर बार एक पैकेज बनाए जाने से बचने के लिए स्वच्छ जड़ को हमेशा वहां रखा जाता है।

Devtools का उपयोग कर संकलन

Devtools स्थापित करें:

# pacman -S devtools

पैकेज बनाने के लिए, Devtools शामिल हैं archbuild, लेकिन आप इसे सीधे नहीं चलाते हैं। इसमें सिम्बलिंक भी शामिल है {extra, gnome-unstable, kde-unstable, staging, testing}-x86_64-build। इसे चलाने के लिए सिम्लिंक का उपयोग किया जा रहा है archbuild, यह निर्धारित करने के लिए कि आप इसे किस लक्ष्य का उपयोग करना चाहते हैं। यह इन अस्थिर / स्टेजिंग / परीक्षण रिपॉजिटरी का उपयोग करने के लिए चलाया जा सकता है, जिनके आधिकारिक रिपॉजिटरी को जारी किए जाने की तुलना में नए संस्करण हो सकते हैं। गैर-AUR पैकेजों के लिए आधिकारिक रिपॉजिटरी का उपयोग करने के लिए, निर्देशिका में PKGBUILD, उदाहरण के लिए git clone, द्वारा बनाई गई निर्देशिका , निम्नलिखित को चलाएँ:

$ extra-x86_64-build

नोट: इस गाइड के बाकी हिस्सों को केवल संदर्भित किया जाएगा extra-x86_64-build।

इसे पूरा करने के बाद, निम्नलिखित परिणाम होंगे:

• /var/lib/archbuild/extra-x86_64/root- एक स्वच्छ chroot है, जो केवल पैकेज समूहों के साथ तारीख स्थापना के लिए एक ऊपर है baseऔर base-devel।
• /var/lib/archbuild/extra-x86_64/<USERNAME>- इसमें बिल्ड चिरोट होगा । यह क्लीन चिरोट की एक प्रति है जो किसी भी निर्भरता के निर्माण या चलाने के लिए आवश्यक है, साथ ही साथ इसका स्रोत कोड, संकलन परिणाम और पैकेज भी।
• जिस निर्देशिका में आप हैं, उसमें पैकेज होगा और लॉग फाइल, साथ ही किसी भी डाउनलोड किए गए स्रोत कोड का निर्माण होगा।

अंत में, आप " Checking PKGBUILD", और " Checking <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz" नोटिस कर सकते हैं । इनके बाद की कोई भी लाइनें आउटपुट हैं namcap, जो स्वचालित रूप से विकृत PKGBUILDफ़ाइलों जैसी समस्याओं की तलाश में हैं , निर्भरता में यह शामिल है कि पैकेज का उपयोग नहीं होता है, निर्भरता में शामिल नहीं है कि पैकेज का उपयोग करने के लिए प्रकट होता है, और अधिक। झूठी सकारात्मक अक्सर द्वारा उत्पन्न की जाती हैं namcap, लेकिन चीजों को जांच के लिए देने के लिए एक महान उपकरण है। यदि आपका पैकेज सही तरीके से काम करता है, तो अनुरक्षक को namcapआउटपुट के लिए सचेत करना एक अच्छा विचार नहीं है , जब तक कि आपने उस पर गौर नहीं किया है और सत्यापित नहीं किया जाना चाहिए।

आप pacmanपैकेज को स्थापित करने के लिए उपयोग कर सकते हैं , जो कि पैकेज को चलाने के लिए आवश्यक किसी भी निर्भरता को स्थापित करेगा जब तक कि वे आधिकारिक रिपॉजिटरी या स्थानीय रिपॉजिटरी में न हों।

या तो यहां बताए अनुसार स्थानीय रिपॉजिटरी का उपयोग करें , या सीधे फाइल इंस्टॉल करें:

# pacman -U <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz

यदि आप extra-x86_64-buildफिर से, अभी या कभी भी इस या किसी अन्य पैकेज के साथ चलना चाहते हैं, तो यह क्लीन चेरोट को अपडेट करेगा यदि आवश्यक हो, तो बिल्ड चिरोट को हटा दें और इसे क्लीन चिरोट की एक नई प्रतिलिपि बनाएँ, और उसी प्रक्रिया को निष्पादित करें। यदि आपकी निर्देशिका में अभी भी पिछली बार से स्रोत कोड डाउनलोड है, तो वह इसका उपयोग करेगा। यदि पैकेज एक विकासात्मक AUR पैकेज है, तो यह पुन: क्लोन के बजाय नए परिवर्तनों को खींच लेगा।

आंतरिक रूप से, extra-x86_64-buildचलाता है makechrootpkg, जो आंतरिक रूप से कॉल करता है makepkg। extra-x86_64-buildनिम्नलिखित में शामिल करने के विकल्प :

• -c: अपने क्लीन चेरोट /var/lib/archbuild/extra-x86_64/सहित सभी डायरेक्टरी को हटाकर और रिक्रिएट करके और उसे सभी क्रॉउट डाइरेक्टरीज़ बनाकर, कैरोट्स को क्लीन करें। यह शायद ही कभी आवश्यक है, केवल अगर साफ चुरोट भ्रष्ट हो जाता है, या अगर देवतूल को इस तरह से अपग्रेड किया जाता है जो पीछे की संगतता को तोड़ता है।
• -r <dir>: /var/lib/archbuild/extra-x86_64/Chroots को शामिल करने की तुलना में एक अलग निर्देशिका का उपयोग करें ।

extra-x86_64-buildबाद के किसी भी तर्क को --पारित कर दिया जाता है makechrootpkg, जब यह आंतरिक रूप से इसका उपयोग करता है। कई तर्क हमेशा अपने आप से पारित हो extra-x86_64-buildजाते हैं makechrootpkg। ये स्वचालित तर्क हैं -r <value given to extra-x86_64-build -r option if given, /var/lib/archbuild/extra-x86_64 otherwise> -c -n। वे makechrootpkgबिल्ड चिरोट को हटाने और इसे क्लीन चिरोट की एक नई प्रति बनाने और namcapपैकेज पर चलाने के लिए कहते हैं यदि यह सफलतापूर्वक जुड़ जाता है। आमतौर पर इस्तेमाल किया जाने वाला विकल्प जिसे पास किया जा सकता makechrootpkgहै -l <copy name>। यह बिल्ड क्रोट को देने के लिए निर्देशिका नाम है <USERNAME>, जो एक ही समय में कई प्रतियों को बनाए रखने या कई पैकेजों को संकलित करने के लिए उपयोगी है।

makechrootpkgबाद के किसी भी तर्क को --पारित किया जाता है makepkg, जब यह आंतरिक रूप से इसका उपयोग पैकेज बनाने के लिए करता है। पहली बार makepkgद्वारा चलाया जाता है makechrootpkg, यह अपने स्वयं के अपरिवर्तनीय विकल्पों के साथ किया जाता है, स्रोत फ़ाइलों को डाउनलोड करने, यदि आवश्यक हो, और अखंडता जांच करने के लिए; इस प्रकार इस रन पर कुछ भी अग्रेषित नहीं किया जा सकता है। यह makepkgपैकेज के निर्माण के लिए दूसरी बार चलता है, और हमेशा स्वचालित रूप से निर्माण चिरोट के भीतर जो कहता है, के makepkgतर्क को स्वचालित रूप से पारित --syncdeps --noconfirm --log --holdver --skipintegकरता है makepkg, स्वचालित रूप से निर्माण के लिए आवश्यक निर्भरताएं स्थापित करता है और पैकेज का उपयोग करने के लिए pacman, के दौरान पुष्टि करने के लिए नहीं , निर्माण प्रक्रिया को पाठ में लॉग ऑन करता है। के अलावा फ़ाइलों stdout, एक संस्करण नियंत्रण प्रणाली में यदि स्रोत कोड को अद्यतन नहीं करते और स्रोत फ़ाइल सत्यापन परीक्षण नहीं करते।

आप निम्न फ़ॉर्म का उपयोग करके इन्हें एक साथ श्रृंखला कर सकते हैं:

$ extra-x86_64-build <DEVTOOLS-OPTIONS> -- <MAKECHROOTPKG-OPTIONS> -- <MAKEPKG-OPTIONS>

ध्यान दें कि /var/lib/archbuildइसे एक अस्थायी निर्देशिका के रूप में माना जा सकता है। यदि आपके पास कई Vultr हार्ड ड्राइव हैं, तो यहां एक RAID0 (स्ट्राइप) फाइल सिस्टम माउंट करना सार्थक है। यदि आपके पास बहुत अधिक रैम है, तो आप रैम समर्थित फाइल-सिस्टम को भी माउंट कर सकते हैं tmpfs। एक पैकेज बनने के बाद, इसे उस निर्देशिका में कॉपी किया जाता है जिसे आप चला रहे extra-x86_64-buildथे और यदि आप चाहते थे, तो इस बिंदु पर आप हटा सकते थे /var/lib/archbuild। अगला रन धीमा होगा, क्योंकि इसे एक नई स्वच्छ जड़ बनाने की आवश्यकता होगी। वैकल्पिक रूप से, आप /var/lib/archbuild/<USERNAME>बिल्ड चेरोट से अतिरिक्त स्थान को पुनः प्राप्त करने के लिए हटा सकते हैं इससे पहले कि यह स्वचालित रूप से Devtools के अगले रन द्वारा हटा दिया जाए। इसलिए, भले ही आपके पास एक RAID0 फाइल सिस्टम था, जो यहां माउंट किया गया था, वह विफल हो गया, सबसे अधिक आप खो देंगे प्रक्रिया में एक संकलन होगा।

Devtools कॉन्फ़िगरेशन फ़ाइलें

Devtools कॉन्फ़िगरेशन फ़ाइलों के साथ नोट करने के लिए कुछ बारीकियाँ हैं। वे में स्थित हैं /usr/share/devtools/, जैसे makepkg-x86_64.confऔर pacman-extra.conf:

• के लिए /etcकी तरह फ़ाइलों makepkg.confऔर pacman.conf, आप सुरक्षित रूप से उन्हें जगह में संपादित कर सकते हैं, और जब पैकेज उन्नत बनाया है, यह आपके परिवर्तनों को अधिलेखित नहीं होंगे। बल्कि यह नई कॉन्फ़िगरेशन फ़ाइलों (यदि वे पिछले संस्करण से बदल गए) को समाप्त होने से बचाएगा .pacnew। हालाँकि, Devtools कॉन्फ़िगरेशन फ़ाइलें हैं /usr/share/जिनमें उपयोगकर्ता को संपादित करने का इरादा नहीं है, इसलिए जब Devtools को उन्नत किया जाता है, तो यह आपको इन फ़ाइलों में परिवर्तन के बिना आपके परिवर्तनों को पूरी तरह से लिख देगा। इस व्यवहार में बदलाव का प्रस्ताव और अस्वीकार कर दिया गया है, क्योंकि यह सुनिश्चित करता है कि संकुल को एक ही संकलन सेटिंग्स के साथ आधिकारिक रिपॉजिटरी में भेजा जाए।
• के लिए मूल्य MAKEFLAGS, PACKAGERऔर {SRC,SRCPKG,PKG,LOG}DESTसे लिया जाता है /etc/makepkg.confके बजाय /usr/share/devtools/makepkg-x86_64.conf।

स्थानीय रिपोजिटरी

यदि आप उन पैकेजों का निर्माण कर रहे हैं जो आपके द्वारा बनाए गए अन्य पैकेजों पर निर्भरता रखते हैं, तो आपको स्थानीय रिपॉजिटरी का उपयोग करने की आवश्यकता होती है, ताकि जब pacmanबिल्ड चेरोट के भीतर चलता है, तो यह निर्भरता पाता है।

स्थानीय रिपॉजिटरी को सेटअप करने के लिए, इस गाइड के "लोकल रिपोजिटरी" सेक्शन को देखें।

एक कस्टम लक्ष्य बनाएं:

# ln -s archbuild /usr/bin/custom-x86_64-build
# cp /usr/share/devtools/pacman-{extra,custom}.conf

संपादित करें /usr/share/devtools/pacman-custom.conf, और अंत में निम्नलिखित जोड़ें:

[archLocalRepo]
SigLevel = Optional TrustAll
Server = file:///archLocalRepo

संपादित करें /etc/pacman.conf, और निम्नलिखित जोड़ें। यह निर्देशिका को चिरोट में बांधने के लिए बाध्य करता है:

CacheDir    = /var/cache/pacman/pkg/ /archLocalRepo/

अब, उपयोग के बजाय extra-x86_64-buildइस का उपयोग करें:

$ custom-x86_64-build

यदि आप हमेशा कस्टम लक्ष्य का उपयोग करना चाहते हैं, तो आप /var/lib/archbuild/extra-x86_64-build/निर्देशिका को हटा सकते हैं यदि यह मौजूद है, जैसा कि चेरोट अब अंदर होगा /var/lib/archbuild/custom-x86_64-build/।

पैकेज तेजी से

नोट थ्रेडिंग पैकेजिंग को सक्षम करने में /usr/share/devtoolsकॉन्फ़िगरेशन फ़ाइलों को संपादित करना शामिल है , जो आधिकारिक तौर पर समर्थित नहीं है, इसलिए आपको हर बार Devtools के अपग्रेड होने पर यह परिवर्तन करने की आवश्यकता होगी।

Devtools एक पुरालेख में एक पूरे पैकेज को जोड़ती है। डिफ़ॉल्ट रूप से, यह संपीड़न के .tar.xzलिए एक एकल थ्रेड का उपयोग करता है xz।

मल्टी सीपीयू सिस्टम पर, आप xzसंपादन करके कई थ्रेड्स का उपयोग करने की अनुमति दे सकते हैं /usr/share/devtools/makepkg-x86_64.conf, और निम्नलिखित लाइन को बदल सकते हैं:

COMPRESSXZ=(xz -c -z -)

आपके पास वर्चुअल कोर के रूप में कई थ्रेड्स की अनुमति देने के लिए:

COMPRESSXZ=(xz -c -z - --threads=0)

कई वर्चुअल कोर का उपयोग करने की अनुमति देने के लिए, लेकिन उनमें से सभी नहीं, ताकि समग्र सिस्टम प्रदर्शन पर प्रभाव को कम करने के लिए, एक विशिष्ट संख्या जोड़ें:

COMPRESSXZ=(xz -c -z - --threads=21)

वर्चुअल कोर की संख्या से अधिक थ्रेड्स निर्दिष्ट करने से आपके प्रदर्शन में कमी आएगी।

यदि आपको पैकेज फ़ाइल होने की संभावना नहीं है (संभावित रूप से) बड़ी, संपादन द्वारा संपीड़न को अक्षम करें /usr/share/devtools/makepkg-x86_64.conf, और निम्न पंक्ति बदलें:

PKGEXT='.pkg.tar.xz'

निम्नलिखित की तरह दिखने के लिए इसे बदलें:

PKGEXT='.pkg.tar'