अधिक हाल के पैकेजों को चाहना किसी भी OS पर एक सामान्य समस्या है। डेबियन के रिलीज़ चक्र ने हाल के वर्षों में औसतन 2 साल का औसत किया है, इसलिए इस चक्र के अंत की ओर, यह शायद अधिक दबाव वाला मुद्दा है। इसे कम करने का एक तरीका यह है कि स्थिर रिलीज चक्र के अंत की ओर परीक्षण किया जाए, जब अगला संस्करण लगभग स्थिर हो। यह इस सवाल से स्पष्ट नहीं है कि क्या यह आम तौर पर परीक्षण और / या अस्थिर के बारे में और अधिक स्थिर होने के बारे में बात कर रहा है। भले ही, सबसे हाल का संस्करण होने पर भी एक मुद्दा हो सकता है अगर कोई अस्थिर है, तो सबसे हाल के संस्करण को अभी तक पैक नहीं किया जा सकता है। डेबियन डेवलपर्स / पैकर्स ग्रामीण स्वयंसेवक हैं, इसलिए वे ऊब सकते हैं, या अन्य चीजों के साथ व्यस्त हो सकते हैं, जिसके परिणामस्वरूप पैकेज कम हो जाता है।
सादगी और संक्षिप्तता के लिए मैं इस बात को मानता हूं कि इस योजना के तहत एक पैकेज को स्थिर करने के लिए है, लेकिन यह आमतौर पर अधिक लागू होता है। तो, यहाँ है कि मैं क्या करूँ अगर मुझे सॉफ़्टवेयर का अधिक हाल का संस्करण चाहिए जो स्थिर में मौजूद नहीं है, लगभग एक अनुमानित क्रम में।
डेबियन बैकपोर्ट में पैकेज की तलाश करें । कभी-कभी आप एक पैकेज पा सकते हैं जो आपके उद्देश्यों को पूरा करने के लिए हाल ही में पर्याप्त है। हालांकि, यह अक्सर ऐसा होता है कि अस्थिर या प्रयोगात्मक या अपस्ट्रीम में संस्करण की तुलना में ये पैकेज पुराने हैं।
परीक्षण, अस्थिर या प्रायोगिक से सीधे पैकेज को स्थापित करने का प्रयास करें। यदि आप जिस भी संस्करण से इंस्टॉल करने का प्रयास कर रहे हैं, उसमें से स्थिर को ज्यादा मोड़ नहीं दिया गया है, तो यह काम कर सकता है। आपको पता चलेगा कि यदि सिस्टम हाल ही के संस्करण से बुनियादी पैकेजों को स्थापित या अपग्रेड करने का प्रयास करना शुरू कर रहा है तो यह एक बुरा है। मान लीजिए आप अस्थिर से स्थापित करने की कोशिश कर रहे हैं, तो
apt-get install packagename/unstable
पहली कोशिश है। स्थिर में संस्करणों के साथ, यह अक्सर विफल हो जाएगा, क्योंकि इसे अस्थिर से अन्य पैकेजों की आवश्यकता होती है, और यह झुकाव केवल packagenameअस्थिर में स्थापित होने के लिए पर्याप्त रूप से उच्च की वरीयता को बढ़ाता है। यदि आपको यह समझ में नहीं आता है कि इसका क्या मतलब है, तो चले जाओ और पढ़ें man
apt_preferences। अस्थिरता से निर्भरता जोड़ने पर, सुनिश्चित करें कि यह मूल पैकेजों को अपग्रेड करने की कोशिश नहीं कर रहा है। उदाहरण के लिए, यदि यह libc6 या X या KDE या Gnome को अपग्रेड करने का प्रयास करना शुरू कर देता है, तो तुरंत गर्भपात करें। यह आमतौर पर ठीक है अगर यह एक ही स्रोत पैकेज से अन्य पैकेजों को अपग्रेड करने की कोशिश करता है, क्योंकि ये आमतौर पर एक साथ कसकर युग्मित होते हैं। यह देखने के लिए कि बाइनरी पैकेज किस स्रोत पैकेज पर निर्भर करता है, करते हैं
apt-cache showsrc packagename
चूंकि बहुत सारा सामान GNU C लाइब्रेरी (libc6) पर निर्भर करता है, इसलिए यह एक समस्या हुआ करती थी। अभी हाल ही में, एपीआई स्थिर हो गया है, इसलिए इसे अपग्रेड न करने के साथ दूर होना अब अधिक बार संभव है। यदि कोई पैकेज स्थिर पर अपनी रनटाइम निर्भरता को संतुष्ट करता है, लेकिन फिर भी सही तरीके से काम नहीं करता है, तो बग दर्ज करें। अगर पैकर आपको बताता है कि यह बग नहीं है, तो वे गलत हैं। :-)
पैकेज का परीक्षण, अस्थिर या प्रायोगिक से खुद को बैकपोर्ट करें।
जैसा कि ऊपर उल्लेख किया गया है, बैकपोर्ट एक विकल्प है, लेकिन अक्सर अस्थिर या प्रयोगात्मक या अपस्ट्रीम में संस्करण की तुलना में ये पैकेज पुराने होते हैं।
यह अक्सर एक पुनरावर्ती निर्भरता निर्माण पाश प्रकार बात की आवश्यकता हो सकती है। आपको पहले बिल्ड निर्भरता प्राप्त करने की आवश्यकता है
apt-get build-dep packagename
यदि यह विफल हो जाता है क्योंकि निर्भरता में से एक हाल ही में पर्याप्त नहीं है, तो आपको पहले उस निर्भरता को वापस करने की आवश्यकता होगी। यह नियंत्रण से बाहर हो सकता है। मैं आमतौर पर छोड़ देता हूं यदि मुझे 2 से अधिक स्तरों की पुनरावृत्ति से निपटना पड़ता है। हालांकि, ध्यान दें कि वास्तविक निर्भरताएं आवश्यक रूप से तंग नहीं होती हैं जैसा कि कहा गया है। एक पुराना संस्करण काम कर सकता है। पैकर एक बिल्ड (या, वास्तव में, रनटाइम) निर्भरता के सबसे पुराने संस्करण को खोजने की कोशिश नहीं करता है जो काम करेगा।
इसी अपस्ट्रीम से संकुल की उपलब्धता की जाँच करें। आदर्श रूप से ये आपके वितरण संस्करण से मेल खाते हैं, लेकिन यदि आवश्यक हो तो आप उनका पुनर्निर्माण भी कर सकते हैं।
परीक्षण / अस्थिर / प्रायोगिक में सबसे हाल के पैकेजों की तुलना में हाल ही में सॉफ़्टवेयर के संस्करण के लिए पैकेज बनाएं। यह अपेक्षाकृत चुनौतीपूर्ण हो सकता है, लेकिन फिर भी कभी-कभी आश्चर्यजनक रूप से उल्लेखनीय है। ध्यान देने वाली पहली बात यह है कि यदि आप पहले से ही डेबियन में पहले से मौजूद पैकेज का अधिक संस्करण तैयार करने की कोशिश कर रहे हैं, तो आप पहले से ही एक बड़े लाभ के साथ शुरू कर सकते हैं, अर्थात् आपके पास काम करने के लिए मौजूदा पैकेजिंग है। बस करो
apt-get source packagename
और apt-getसंबंधित स्रोत पैकेज डाउनलोड करेगा, जिसमें डेबियन उपनिर्देशिका भी शामिल है, जहाँ पैकेजिंग रहती है। इसके अलावा ध्यान दें कि इन दिनों, यह पैकेजिंग अक्सर कुछ verson कंट्रोल रिपॉजिटरी के अंदर रहती है (git, Debian के साथ लोकप्रिय लगती है) और स्थिर apt (वर्तमान में 0.8.10.3 ) आपको यह बताने में मदद करती है कि यह कहाँ है
apt-get source। आपको इस पर गौर करना चाहिए, क्योंकि किसी भी रिलीज़ किए गए पैकेज से मेल खाते हुए पैकर्स में पैकेजिंग के हाल के संस्करण हो सकते हैं। उदाहरण के लिए।
$ apt-get source mercurial
Reading package lists... Done
Building dependency tree
Reading state information... Done
NOTICE: 'mercurial' packaging is maintained in the 'Svn' version control system at:
svn://svn.debian.org/python-apps/packages/mercurial/trunk
वैकल्पिक रूप से, आप बस उपयोग कर सकते हैं
apt-cache showsrc mercurial | grep Vcs
भंडार को सूचीबद्ध करने के लिए।
यदि पैकेज बुरी तरह से पुराना है, तो आपको
पैकेज में संशोधन करना पड़ सकता है , लागू पैच को ताज़ा कर सकते हैं लेकिन यह अभी भी आमतौर पर एक अच्छा प्रारंभिक
बिंदु है। डेबियन
प्रति -डीपी-स्रोत 3.0 (रजाई) प्रारूप में रजाई पर पैकेज प्रबंधन के मानकीकरण की प्रक्रिया में लगता है , ताकि पैच रीफ्रेशिंग में मदद मिले।
मैं एक वास्तविक जीवन के उदाहरण के साथ समाप्त करता हूं कि कैसे मैंने pgf के डेबियन पैकेज को
वापस भेज दिया । 2008 में pgf का अंतिम पैकेज्ड संस्करण 2.00 था और तब से 2.10 जारी किया गया था। पीजीएफ (2.10) के नवीनतम स्थिर संस्करण , और पैच, पीजीएफ: 2.0 डेबियन पैकेजिंग के खिलाफ पैच के साथ मेरे फॉलोअप बग पर चर्चा करें । जैसा कि यह पता चला है, pgf की डेबियन पैकेजिंग बहुत सरल थी, और मुझे इसे काम करने के लिए बस 2.10 पैकेजिंग में एक लाइन बदलनी पड़ी। मैंने सभी लिंटियन शिकायतों को भी समाप्त कर दिया
, लेकिन यह सख्ती से वैकल्पिक था।