हैकेज

Question

पर गैर-रखरखाव अपलोड मेरे पास हैकेज पर एक पैकेज है जो तीसरे पक्ष के पैकेज पर निर्भर करता है, जो जीएचसी (> = 7.2) के नए संस्करणों पर आधारित नहीं है। अन्य पैकेज के साथ समस्या को केवल एक लाइन पैच (LANGUAGE प्रागमा) के साथ हल किया जा सकता है। मैंने पैच को अपस्ट्रीम में दो बार भेजा, लेकिन कोई प्रतिक्रिया नहीं मिली। समस्या यह है कि मेरा पैकेज इंस्टॉल करने योग्य नहीं है और न ही निर्भरता तय होने तक।

मैं डिप्नेसी पैकेज (एक मामूली संस्करण टक्कर के साथ) का निश्चित संस्करण अपलोड कर सकता था, लेकिन मैं यह सुनना चाहता हूं कि इस तरह के गैर-रखरखाव अपलोड के बारे में समुदाय का दृष्टिकोण क्या है। दोबारा, मैं लाइब्रेरी इंटरफ़ेस को बदलना नहीं चाहता, मैं इसे फिर से बनाने योग्य बनाने के लिए एक नया संकलन ध्वज जोड़ता हूं।

• क्या हैकेज को गैर-रखरखाव अपलोड की अनुमति है और सहन किया जाता है?
• जब हैकेज पर पैकेज का कांटा बेहतर दृष्टिकोण है?

Answer 1

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

लेकिन एक बेहतर स्थापित उत्तर संभव होगा यदि हमें पता था कि कौन सा पैकेज संबंधित है और ठोस स्थिति को देख सकता है।

Answer 2

एक forking के एक पैकेज है कि यदि आपको संदेह अभी भी बनाए रखा है के लिए घुसपैठ है, लेकिन लेखक अस्थायी रूप से अनुपलब्ध है। घुसपैठ करके, मेरा मतलब है कि अन्य प्रोग्रामर आपकी कांटा उठा सकते हैं, फिर मूल लेखक ने मुख्य लाइन पर काम शुरू करने के बाद मुख्य लाइन पर वापस नहीं जा सकते।

उन पैकेजों के लिए जहां मूल लेखक ने हास्केल समुदाय छोड़ दिया है, मेरी व्यक्तिगत राय यह है कि यदि आप इसे और विकसित करने जा रहे हैं तो पैकेज को फोर्क करना बेहतर होगा। फोर्किंग उत्तराधिकार की समस्याओं को रोकती है, जैसे कि पारसेक के साथ हुआ जहां कई डेवलपर्स अपडेट नहीं करना चाहते थे क्योंकि उत्तराधिकारी कुछ समय के लिए मूल से धीमा और कम दस्तावेज था।

कैफे पर पूछने के सभी मामलों में सबसे अच्छा है, इस पर ध्यान दिए बिना कि लोगों ने इसका पालन नहीं करना चुना है, यह अभी भी हास्केल समुदाय का केंद्र है।

प्रश्न में विशेष मामले के लिए, जबकि यह अच्छा है कि हैकेज संकलन पर चीजें हैं, ऐसा कोई नियम नहीं है जो उन्हें कहता है। एक पैकेज जो टूटे हुए पैकेज पर निर्भर करता है, आसानी से टूटी हुई निर्भरता के लिए इसके सामने वाले पृष्ठ पर परिवर्तन निर्देश डाल सकता है, यानी "यह पैकेज LambdaThing-0.2.0 पर निर्भर करता है जो कि LambdaThing जोड़ने ... फ़ाइल Lambda को ठीक करने के लिए टूटा हुआ है। एचएस "

Answer 3

मैं कहूंगा, विशिष्ट पैकेज और अनुपलब्ध विशिष्ट व्यक्ति के संबंध में मेलिंग सूचियों से परामर्श करना बहुत अच्छा विचार है। मैंने अपने मूल मालिक से हैकेल-src-meta पैकेज पर नियंत्रण लिया, लेकिन केवल सूचियों और आईआरसी से परामर्श करने के बाद, जिन्होंने मुझे आश्वासन दिया कि मैट मोरो महीनों के लिए गायब था और कोई भी नहीं जानता था कि क्यों।

मेरी राय में, पैकेज स्वामित्व शायद ही बदला जाना चाहिए जहां ऐसा करने की सर्वसम्मति है, या कम से कम एक को खोजने के लिए प्रयास किए जाने चाहिए। हैकेज सॉफ़्टवेयर के विकास संस्करण में, यह मेरी समझ है कि एक्सेस नियंत्रण हैं ताकि केवल प्रशासक इस तरह के हस्तक्षेप कर सकें।