-Dbg, -dev, -doc पैकेज कैसे और क्यों बनाएं?


15

मैं एक पैकेज के लिए एक उबंटू पैकेज लिख रहा हूं जो अनिवार्य रूप से कई पुस्तकालयों और हेडर प्रदान करता है जो तब अन्य सॉफ़्टवेयर बनाने के लिए उपयोग किया जाता है। पैकेज छोटे उप-पैकेजों में भी टूट जाता है जो अन्योन्याश्रित होते हैं; इस अर्थ में पैकेज को बढ़ावा देने के लिए काफी समान है।

मैंने देखा कि बूस्ट जैसे पैकेज प्रदान करते हैं

[...]
libboost-dbg
libboost-dev
libboost-doc
[...]
libboost-all-dev
[...]

लेकिन कुछ भी नहीं है कि नाम से boostया जाता है libboost

  • इसके पीछे क्या विचार है?
  • के प्रयोजनों के क्या हैं -dbg, -devऔर -docसंकुल?
  • क्या उन पैकेजों के लिए फ़ाइलों को लिखने के लिए कोई निर्देश दिए गए हैं?

जवाबों:


13

विचार और उद्देश्य

इन अलग-अलग पैकेजों को अलग करने का मुख्य कारण डिस्क स्थान और डाउनलोड गति है। विशेष रूप से, यह दर्पण अंतरिक्ष के लिए एक बड़ी चिंता का विषय है क्योंकि इसका मतलब है डेटा की कई प्रतियां वितरित करना। करके foo-common, foo-dataया foo-docसंकुलArchitecture: all , हम केवल एक के बजाय संग्रह में डेटा की की नकल यह प्रत्येक वास्तुकला के साथ की नकल की हो रही रखने के (जैसे i386, amd64, ect ...)। अधिकांश उपयोगकर्ताओं द्वारा डिबगिंग प्रतीकों की आवश्यकता नहीं होती है और केवल पैकेज डाउनलोड को अधिक समय लेने की आवश्यकता होती है।

आधिकारिक उबंटू अभिलेखागार में पैकेज के लिए, वास्तव में -dbgमैन्युअल रूप से पैकेज बनाने का कोई कारण नहीं है । निर्माण मशीनें स्वचालित रूप से डिबगिंग प्रतीकों को हटा देती हैं और उन्हें -dbgsymddebs.ubuntu.com पर होस्ट किए गए पैकेजों में डाल देती हैं। (देखें: डिबग सिंबल पैकेज ) जो -dbgपैकेज मौजूद हैं वे आमतौर पर डेबियन से लिए जाते हैं।

अनुदेश

कार्यान्वयन के लिए, इस प्रश्न पर एक नज़र डालें:

संक्षेप में, debian/controlप्रत्येक पैकेज के लिए नए श्लोक बनाने की आवश्यकता है । फिर debian/foo-*.installफाइलों को भी बनाने की जरूरत है। यह dh_installसही सामग्री को सही पैकेजों में डालने की अनुमति देगा ।

foo.installमुख्य बाइनरी पैकेज के लिए ऐसा लग सकता है:

usr/bin/
usr/lib/

foo-common.install, foo-data.install, foo-doc.install, या जो कुछ भी:

/usr/share/doc/
/usr/share/icons/
/usr/share/foo/
/usr/share/locale/

और इसके लिए foo-dev:

/usr/include/
/usr/lib/pkgconfig
/usr/lib/*.so

foo-dbgपैकेज बनाने के लिए संपादन की आवश्यकता होती है debian/rulesक्योंकि आम तौर पर dh_stripडिबगिंग प्रतीकों को हटा दिया जाएगा। इसलिए हमें उस व्यवहार को ओवरराइड करने की आवश्यकता है:

.PHONY: override_dh_strip
override_dh_strip:
        dh_strip --dbg-package=foo-dbg

12

बूस्ट एक जटिल उदाहरण है, आइए पहले एक सरल को देखें।

सटीक में, खुलता स्रोत पैकेज 5 बाइनरी पैकेज प्रदान करता है:

  • libssl1.0.0OpenSSL डायनेमिक लाइब्रेरी, संस्करण 1.0.0 शामिल है। इस पुस्तकालय से जुड़े कार्यक्रमों को चलाने की जरूरत है। पैकेज नाम में एक संस्करण संख्या होती है क्योंकि आपके पास एक ही समय में लाइब्रेरी के अन्य संस्करण हो सकते हैं, यदि आपके पास अन्य प्रोग्राम हैं जो किसी अन्य संस्करण से जुड़ा हुआ है जो कि बाइनरी-संगत नहीं है।
  • opensslइसमें कमांड लाइन टूल शामिल है जो ओपनएसएसएल लाइब्रेरी का उपयोग करता है। यहां तक ​​कि अगर आपके पास पुस्तकालय के कई संस्करण हैं, तो आपको इन उपकरणों के कई संस्करणों की आवश्यकता नहीं है: बस एक /usr/bin/opensslऔर संबंधित उपकरण, डेटा और प्रलेखन है।
  • libssl-devयदि आप एक प्रोग्राम को संकलित करना चाहते हैं, जो OpenSSL के विरुद्ध लिंक करना चाहता है, तो इसमें फ़ाइलें हैं। सी हेडर फाइलें ( *.h), लिंक करने के लिए पुस्तकालय ( *.a, *.so), और कुछ मिश्रित फाइलें हैं।
  • libssl-docOpenSSL लाइब्रेरी के लिए प्रलेखन शामिल है। यदि आपको लाइब्रेरी का उपयोग करने वाले प्रोग्राम लिखने हैं तो आपको केवल इस पैकेज की आवश्यकता होगी।
  • libssl1.0.0-dbgजिसमें डिबगिंग प्रतीक हैं। यह केवल उन लोगों के लिए उपयोगी है जो OpenSSL लाइब्रेरी या प्रोग्राम का उपयोग करते हैं। andrewsomething का उत्तर इन -dbgपैकेजों पर अधिक जानकारी रखता है।

इसके अलावा, सटीक में लाइब्रेरी का एक पुराना संस्करण शामिल है libssl0.9.8, क्योंकि ऐसे प्रोग्राम हैं जो अभी भी पुराने संस्करण के खिलाफ जुड़े हुए हैं।

अन्य पैकेज जिन्हें आप देख सकते हैं, सी। ओपनएसएसएल के अलावा अन्य भाषाओं के लिए बाइंडिंग हैं (किसी भी अन्य भाषाओं के लिए ओपनएसएसएल के लिए बाइंडिंग नहीं हैं, लेकिन वे एक ही स्रोत से नहीं आते हैं)। एक उदाहरण sqlite3 है , जो बंधन बाइंडिंग के साथ जहाज करता है ।

इस तरह के पैकेजों को विभाजित करने का मुख्य कारण यह है कि विभिन्न पैकेजों में अलग-अलग लक्ष्य दर्शक होते हैं। एक प्रणाली जहां कोई भी कभी भी कुछ भी संकलित नहीं करता है केवल कोर libपैकेज की आवश्यकता होती है , और शायद कमांड लाइन टूल; यदि आवश्यक हो तो वे स्वचालित रूप से निर्भरता से स्थापित हो जाएंगे। यदि कोई लाइब्रेरी का उपयोग करने वाले प्रोग्राम को संकलित करना चाहता है, तो उन्हें -devपैकेज की आवश्यकता होती है । यदि कोई ऐसा प्रोग्राम लिखना चाहता है जो लाइब्रेरी का उपयोग करता है, तो उन्हें -docपैकेज की आवश्यकता होती है ।

तो बूस्ट का क्या? यह उसी संरचना का अनुसरण करता है, लेकिन क्योंकि बूस्ट एक विशाल पुस्तकालय है, यह कई छोटे पैकेजों में टूट गया है: libboost-*1.46.1और libboost-*1.46-dev। सटीक रूप से, बूस्ट का केवल एक संस्करण है, 1.46 , लेकिन वनैरिक में 1.42 और 1.46 दोनों थे । एक रूपक बढ़ावा-चूक भी है जो एक निर्भरता के रूप में संस्करण पैकेज में खींचती है।

कामचलाऊ पुस्तकालय को देखते हुए , गतिशील पुस्तकालय पैकेज libhangul1और विकास पैकेज के अलावा libhangul-dev, एक पैकेज है libhangul-data। इस पैकेज में अतिरिक्त डेटा है जो लाइब्रेरी द्वारा आवश्यक है। यहां तक ​​कि अगर आपके पास पुस्तकालय के कई संस्करण हैं, तो वे -dataपैकेज साझा कर सकते हैं । इसके अलावा, पैकेज वास्तुकला-स्वतंत्र है। सॉफ़्टवेयर जिसमें बड़ी मात्रा में आर्किटेक्चर-इंडिपेंडेंट डेटा होता है, उसे डिस्ट्रीब्यूशन साइट्स पर जगह बचाने के लिए आर्किटेक्चर-डिपेंडेंट और आर्किटेक्चर-इंडिपेंडेंट पैकेज में विभाजित किया जाता है। इसी तरह के अर्थ के साथ एक और प्रत्यय है -common

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.