Gitea: बिंट्रे के माध्यम से रिलीज और डिबेट/आरपीएम पैकेज प्रदान करें

क्या हमें वास्तव में deb/rpm की आवश्यकता है? क्या केवल डोकर चित्र ही पर्याप्त नहीं हैं? इडक, मुझे गलत साबित करो! :)

ड्रोन में केवल डॉकर छवियां होती हैं, है ना?

Gogs packager.io का उपयोग कर रहा है, उसका पुन: उपयोग क्यों न करें?

क्योंकि हर कोई docker का उपयोग नहीं करता/करेगा।

Packager.io केवल lts संस्करणों का समर्थन करता है, इसके अलावा, Packager.io के ओवरहेड की तुलना में गोलांग पैकेजिंग को बहुत आसान किया जा सकता है।

ठीक है, मुझे गो के बारे में पर्याप्त जानकारी नहीं है। लेकिन उबंटू 16.04 के लिए समाधान होना बहुत अच्छा होगा, क्योंकि https://github.com/gogits/gogs/pull/3617 विलय नहीं हुआ :(

किसी भी उबंटू/डेबियन/जो भी संस्करण के लिए पैकेज प्रदान करने के लिए हम उसी बाइनरी को पैकेज में लपेट सकते हैं और केवल init (sysvinit, systemd) स्क्रिप्ट को समायोजित करने की आवश्यकता है।

क्या हम 16.04 packager.io PR को मर्ज कर सकते हैं और कुछ समय के लिए उस पर गीत को सक्षम कर सकते हैं?

बाइनरी और डॉकर दोनों की जरूरत है।

क्या हम 16.04 packager.io PR को मर्ज कर सकते हैं और कुछ समय के लिए उस पर गीत को सक्षम कर सकते हैं?

हमने अभी तक वहां कुछ भी सक्षम नहीं किया है, लेकिन चूंकि इस मुद्दे का अनुमान 1.0.0 है, इसलिए मैं इसे अपनी पहली रिलीज के लिए पेश करना चाहता हूं।

मुझे बाइनरी रिलीज़ भी चाहिए - मेरे पास चीजों को संकलित करने के लिए गो डेवलपमेंट एनवायरनमेंट सेटअप नहीं है।

साथ ही, क्या मैं गॉग्स से गीता में अपग्रेड कर पाऊंगा? मुझे अपने मुद्दों आदि को ढीला करने से नफरत होगी।

हमारे पास बाइनरी रिलीज़ होंगे और उम्मीद है कि प्रमुख लिनक्स वितरण के लिए भी पैकेज होंगे। आपको कुछ भी संकलित करने की आवश्यकता नहीं है।

हमारे पास नवीनतम मास्टर संस्करण के लिए बायनेरिज़ भी होंगे।

आप सीधे गॉग्स डेटाबेस के साथ गीता लॉन्च करने में सक्षम होंगे। यदि हमें डेटाबेस परिवर्तन मिलते हैं तो वे स्वचालित रूप से माइग्रेट हो रहे हैं।

ओह कमाल लगता है! मैं इसके लिए उत्सुक हूँ तो

-- Starbeamrainbowlabs (keybase.io/sbrl)

https://packagecloud.io (ओएसएस - 25 जीबी स्टोरेज / 250 जीबी बैंडविड्थ + सीडीएन bintray.com 1TB/m)

@tboerger https://packagecloud.io/docs#os_distro_version LTS और गैर-LTS deb/rpm/etc…
प्राथमिक ओएस / रास्पियन / उबंटू / डेबियन / एसयूएसई लिनक्स एंटरप्राइज सर्वर / ओपनएसयूएसई / फेडोरा / लिनक्समिंट / पोकी डिस्ट्रो / ओरेकल लिनक्स / वैज्ञानिक लिनक्स / एंटरप्राइज लिनक्स (सेंटोस, रेडहैट, अमेज़ॅन लिनक्स)

@denji हाँ मुझे पैकेजक्लाउड पता है, शायद हम इसे ले लेंगे, लेकिन इसके लिए हमें ड्रोन प्लगइन की आवश्यकता है :)

यह 1.0.0 के लिए नहीं होगा, इसलिए मैं इसे 1.1.0 पर ले जाऊंगा।

गॉग्स पहले से ही डिबेट और आरपीएम पैकेज प्रदान करता है, इसलिए यह एक वास्तविक दया होगी यदि यह 1.0.0 के लिए नहीं होगा।

क्या मैं Gogs 0.9.99.0903 को Gitea 1.1.0 में बिना किसी समस्या के अपडेट कर पाऊंगा?

गोग्स एक ऐसी सेवा का उपयोग कर रहा है जो केवल एलटीएस संस्करणों का समर्थन करती है और जो कुछ अजीब बाइनरी रैपिंग करती है। हम एक वास्तविक समाधान चाहते हैं।

मुझे लगता है कि आप Gogs 0.9.99.0903 से Gita 1.1.0 में अपग्रेड कर सकते हैं।

@tboerger ऐसा कुछ करने के बारे में क्या? https://blog.codeship.com/using-docker-build-debian-packages/

@lunny मैं अनुमान लगा रहा हूँ @jhasse का अर्थ है apt-get upgrade . द्वारा अपग्रेड करना

एक सादा उपयुक्त-अपग्रेड काम नहीं करेगा क्योंकि हमारे पास एक अलग पैकेज नाम होगा। लेकिन मुझे लगता है कि यह apt-get remove gogs && apt-get install gita करने के लिए काम करेगा :)

इसके बाद उन्हें Gogs के app.ini को Gitea में कॉपी करना होगा।

इसके बाद उन्हें Gogs के app.ini को Gitea में कॉपी करना होगा।

हालांकि, उन्हें apt-get install gitea से पहले ऐसा करना होगा, अन्यथा सेवा पहले ही शुरू हो चुकी होती।

@jhasse IIRC डेबियन पैकेजिंग नियम इंस्टॉल पर ऑटो-सक्षम सेवाओं को मना करते हैं: पलक:

आप इसे कॉन्फ़िगर कर सकते हैं: http://askubuntu.com/questions/365911/why-the-services-do-not-start-at-installation

और मुझे लगता है कि उबंटू पर डिफ़ॉल्ट उन्हें स्वतः सक्षम करना है। कम से कम जब मैंने Ubuntu 14.04 पर Gogs स्थापित किया तो मुझे इसे मैन्युअल रूप से करने की आवश्यकता नहीं थी।

यह सच है कि packager.io बाइनरी रैपिंग करता है, लेकिन गॉग्स/गीता के लिए इसकी आवश्यकता होती है। कई पर्यावरण चर स्थापित करने की आवश्यकता है, आदि। मैंने CentOS 6 gogs RPM को स्थापित करने और स्थापित करने के लिए बहुत सरल पाया।
आप गीता के लिए जो भी पैकेजिंग समाधान चुनते हैं, कृपया सुनिश्चित करें कि इसे स्थापित करना, कॉन्फ़िगर करना और अपग्रेड करना आसान है।

कई पैकेज पर्यावरण चर पर निर्भर करते हैं, फिर भी बाइनरी को लपेटने की कोई आवश्यकता नहीं है। और स्थापित करने और कॉन्फ़िगर करने में आसान हमेशा पैकेज का फोकस होता है या नहीं?

इसलिए मैंने वास्तव में गीता को .deb में पैक किया है। मैं अपने सर्वर पर कुछ भी अनुमति नहीं देता जो ठीक से पैक नहीं किया गया है। यह इस समय थोड़ा सा चिथड़े का काम है (आंशिक रूप से इस #480 के कारण)।

अपग्रेड पथ के विषय पर... .deb संकुल कुछ फाइलों को "कॉन्फ़िगर" फाइलों के रूप में घोषित करने की अनुमति देता है जो पैकेज प्रबंधक करेगा:

• पैकेज को अनइंस्टॉल करने के बाद तब तक रखें जब तक कि उपयोगकर्ता स्पष्ट रूप से पैकेज को "शुद्ध" न कर दे
• अपग्रेड के साथ ओवरराइट करने से पहले संशोधन की जांच करें। यह उपयोगकर्ता से पूछेगा कि यदि कॉन्फ़िगरेशन बदल गया है तो क्या करना है।

यह .deb को डिफ़ॉल्ट app.ini फ़ाइल को शामिल करने की अनुमति देता है जिसमें डिफ़ॉल्ट का एक गुच्छा होता है जो कोर गिटिया डिफ़ॉल्ट से अलग होता है (उदाहरण: # 480 में उल्लिखित फ़ाइल पथ)।

अन्य पैकेजों (जैसे गॉग्स) को अप्रचलित करने के लिए एक तंत्र भी है, लेकिन यह कम उपयोगी हो सकता है यदि गॉग्स को .deb के बिना स्थापित किया गया हो

मेरे कॉन्फ़िग कोड के इर्द-गिर्द प्रहार करने में रुचि रखने वाले किसी भी व्यक्ति के लिए यहाँ है: https://github.com/couling/gitea/tree/dpkg-config/scripts/dpkg

मैं एक पुरानी स्क्रिप्ट का उपयोग करके पैकेज ( मेरी कॉन्फ़िगरेशन में मेनिफेस्ट फ़ाइल के आधार पर) का निर्माण करता हूं जिसे मैंने अभी तक ओपन-सोर्स नहीं फेंका है, लेकिन अगर यह मदद करता है तो मैं जल्द ही ऐसा कर सकता हूं।

@jhasse IIRC डेबियन पैकेजिंग नियम इंस्टॉल पर ऑटो-सक्षम सेवाओं को मना करते हैं

यह तो दिलचस्प है। जब मैंने इंस्टॉल किया तो प्रत्येक सर्वर पैकेज (अपाचे 2 जैसी चीजों सहित) ने सेवा शुरू कर दी है।

@couling क्या आप पीआर भेज सकते हैं?

@tboerger कोई अपडेट?

मेरी तरफ से अभी तक कोई अपडेट नहीं आया है। आईएमएचओ हमें यह सुनिश्चित करने के लिए अलग-अलग डॉकटर कंटेनर चलाने की जरूरत है कि यह लक्ष्य ओएस से ठीक से मेल खा रहा है (ग्लिबैक मुद्दे का जिक्र करते हुए)। इसके अलावा एक डॉकटर वर्कफ़्लो 32 बिट सिस्टम और अन्य आर्किटेक्चर को बाहर करता है क्योंकि हम अभी तक अपने बिल्डचैन के साथ इसका समर्थन नहीं कर सकते हैं।

तो चलिए इसे v1.2 में डालते हैं?

मुझे यकीन नहीं है कि यह मददगार है। लेकिन मेरे पास डेबियन एट-ऑल (सिर्फ देशी गोलंग) का उपयोग किए बिना डेबियन पैकेज बनाने के लिए एक प्रायोगिक गोलंग लिब/टूल है। "क्रॉस-प्लेटफ़ॉर्म" तरीके से डेबियन के लिए पैकेज बनाते समय मुझे कुछ "समस्याएं" भी हुईं और मैं dpkg बिल्डर का बहुत बड़ा प्रशंसक नहीं हूं। एक नज़र डालें: https://github.com/xor-gate/debpkg

यह अभी भी प्रायोगिक चरण में है, लेकिन यह संस्थापन योग्य पैकेज उत्पन्न करने में सक्षम है।

@ xor-gate धन्यवाद, जब मैं इस मुद्दे पर वापस आऊंगा तो एक नज़र डालेगा।

मैं डेबियन के लिए गीता की पैकेजिंग पर एक स्टैब लेने जा रहा था, लेकिन मैं देख रहा हूं कि किसी और ने मुझे पीटा है - डेबियन बग 79210 देखें।

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

मुझे उन सभी गीता निर्भरता के लिए पैकेज विवरण लिखने में सबसे अधिक मदद चाहिए जो वर्तमान में डेबियन में पैक नहीं की गई हैं। यह मेरा कम से कम 80% समय ले रहा है क्योंकि मेरे गोलंग कौशल कमजोर हैं और इनमें से कई विभागों के पास उनके बारे में बहुत कम या कोई विवरण नहीं है। मैं कुछ और डेबियन-बिल्ड सामान से भी लड़ रहा हूं।

यदि आप, या कोई और चाहते हैं 1. डेबियन 2 स्थापित करें। उपयुक्त-गेटा स्थापित करें, मुझे एक हाथ देना चाहते हैं, आईआरसी पर मुझे मारने के लिए स्वतंत्र महसूस करें! एमटेकनोलॉजी @ फ़्रीनोड/ओएफटीसी

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

@mjturner मुझे लगता है कि मैंने तुम्हें डरा दिया है! यदि आप अभी भी रुचि रखते हैं, तो मैं ऐसी जगह पर हूं जहां यह थोड़ा भारी हो रहा है और मैं वास्तव में एक हाथ का उपयोग कर सकता हूं।
या.. कोई और? कोई भी जो डेबियन पैकेजिंग और/या गो को समझता है? प्रिटी प्लीज... :रो:

हाय दोस्तों, डेबियन पैकेजिंग बहुत सहज नहीं है क्योंकि यह बहुत लचीला है। ज्यादातर लोग बस कुछ फाइलों को .deb और कुछ मेटा (पैकेज, संस्करण, विवरण) के अंदर चाहते हैं। मुझे लगता है कि एक साधारण डेबियन पैकेज बनाने के लिए कुछ फ्रंटएंड टूल्स का उपयोग करने का सबसे तेज़ तरीका है। जैसे https://github.com/laher/goxc या https://github.com/jordansissel/fpm।

सिंकथिंग (गोलंग प्रोजेक्ट) के लोग अपनी build.go स्क्रिप्ट में डेबियन पैकेज बनाने के लिए FPM का उपयोग करते हैं:
https://github.com/syncthing/syncthing/blob/2579e8f7152c3205691f3798a81d43c1af4e8af6/build.go#L531 -L539

कुछ लोगों ने dh-make-golang (गोलंग के लिए डेबियन हेल्पर मेक) के लिए डेबियन मेक बिल्ड सिस्टम में पहले से ही कुछ प्रयास किए हैं, देखें https://github.com/Debian/dh-make-golang।

इसे डेबियन के लिए पैकेज करने के लिए कुछ प्यार की जरूरत है, लेकिन यह प्रयास के लायक है।

@MTecknology माफ़ी! मैं निश्चित रूप से भयभीत नहीं हुआ हूं, मैं बस एक टन अन्य चीजों के साथ इतना डूब गया हूं कि मुझे कुछ हफ्ते पहले हमारे पिछले संपर्क के बाद से गीता को एक और रूप देने का मौका नहीं मिला है :(

मेरा समय अभी भी काफी सीमित है, लेकिन मैं अभी भी इसमें शामिल होने के लिए बहुत उत्सुक हूं।

चिंता न करें। यह परियोजना किसी भी उचित, समझदार, या अच्छी तरह से समायोजित व्यक्ति से कहीं अधिक है जिसे कभी भी खींचने का प्रयास करना चाहिए। अभी मुझे लगता है कि मैं संस्करण असंगतताओं से निपट रहा हूं जहां निर्माण सफल होता है लेकिन रनटाइम परिणाम एक सेगफॉल्ट है। कम से कम यह अंततः एक नीति-अनुपालन निर्माण है।

यह पता चला है कि मुझे पैक की गई कुछ अतिरिक्त जावास्क्रिप्ट पुस्तकालयों की आवश्यकता है। अधिक... वूहू..... :सोब:

@MTecknology किसी भी मौके पर आप अपने वर्तमान WIP पैकेज (जैसे सार्वजनिक रेपो के माध्यम से) साझा कर सकते हैं? दूसरों को शामिल करने के लिए प्रोत्साहित करने में मदद मिल सकती है।

@mjturner heheh ... आपने वास्तव में एक लिंक पोस्ट किया है जहां मैंने अपने डब्ल्यूआईपी (डेबियन बग) के लिए एक लिंक पोस्ट किया है।
-> https://github.com/MTecknology/gita-wip/blob/master/work_in_progress

इस सूत्र पर मेरी पिछली टिप्पणी के बाद से कोई महत्वपूर्ण परिवर्तन नहीं हुआ है। मैं एक वास्तविक निर्माण प्राप्त करने में कामयाब रहा, लेकिन यह segfaults है। मेरे पास एक बहुत ही ठोस कूबड़ है जो segfaults बेमेल पुस्तकालय संस्करणों के कारण थे। मेरे पास अस्थिर में शामिल नए बिल्ड डिप्स के अधिकांश (~ 90) हैं, लेकिन इससे पहले कि मैं कुछ भी अपडेट करने पर विचार कर सकूं, मुझे फ्रीज होने तक इंतजार करना होगा। (बहुत जल्दी)

इस समय, मुझे जावास्क्रिप्ट पैकेज/निर्भरता के साथ सबसे अधिक सहायता की आवश्यकता है।

यह अन्य बातों के अलावा #1484 तक रुकने वाला है, लेकिन डेबियन 9 जारी किया गया है और मैं निकट भविष्य में फिर से कुछ प्रगति करने की योजना बना रहा हूं। अभी भी बहुत कुछ करना बाकी है, लेकिन मैं किसी दिन इस चूसने वाले को बंद करवा दूँगा!

हैलो, क्या किसी ने फेडोरा/सेंटोस/आरएचएल में सफलतापूर्वक आरपीएम बनाया है?

@tboerger - आप और आपकी टीम गीता के साथ जो कर रही है, वह मुझे बहुत पसंद है! लोगों की चिंताओं को दूर करने के लिए गीता के पास अभी तक आरपीएम नहीं हैं, मैंने रेड हैट डेरिवेटिव 6.x और 7.x के लिए गीता आरपीएमएस उत्पन्न करने के लिए एक उपकरण लिखा है। मैं अभी कुछ समय से इसका स्थानीय स्तर पर परीक्षण कर रहा हूं और मैं वास्तव में इसे अगले या दो दिनों में रिलीज करने के करीब हूं।

सुनिश्चित नहीं हैं कि आप RPMS बनाने के लिए GO समाधान की तलाश कर रहे हैं या यदि आप केवल RPM बनाने वाली प्रक्रिया चाहते हैं। मेरा उपकरण (भले ही यह ज्यादातर अजगर में लिखा गया है) RPMS उत्पन्न करेगा जो Redhat के पैकेजिंग मानकों के अनुरूप है।

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

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

@codylane इसके लिए तत्पर हैं! मैं फेडोरा पैकेजिंग तरीके का उपयोग करके ऐसा करने पर काम कर रहा था, लेकिन मुझे मुश्किल से पता है कि यह कैसे करना है और अंधेरे में एक शॉट बनने जा रहा था।

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

मुझे गीता के लिए एक पुल अनुरोध सबमिट करने में खुशी होगी, बस लगा कि समुदाय यह सुनिश्चित करने में मेरी मदद कर सकता है कि यह आपके रेपो में जाने से पहले काम करता है। मेरे पास आरपीएम के आसपास बहुत सारे एकीकरण परीक्षण हैं लेकिन यह सुनिश्चित करने का सबसे अच्छा तरीका लोगों के सामने है। :)

इतना बढ़िया ओपन सोर्स टूल बनाने के लिए फिर से धन्यवाद!

हो सकता है कि यह ड्रोन प्लगइन के लिए कुछ जमीनी काम भी हो, पहले से ही किसी अन्य देव से बात की हो जिसने ड्रोन के लिए एक डिबेट प्लगइन बनाया हो।

ठंडा। मुझे ड्रोन को भी चेकआउट करने की ज़रूरत है और यह खेलने के लिए मेरी चीजों की सूची में है।

जैसा कि वादा किया गया था, यहाँ CentOS 6 और 7 के लिए Gitea RPM बनाने के लिए एक स्वचालित CI प्रक्रिया है। https://github.com/codylane/gitea-rpm।

कृपया मुझे बताएं कि क्या आप प्रश्न या चिंताएं हैं या यदि कोई समस्या है। मैंने पहले ही सिस्टमड के साथ एक छोटा सा मुद्दा खोल दिया है। मैं इसे कल ठीक कर दूंगा।

क्या आपने कॉपर का उपयोग करने के बारे में सोचा है?

हो सकता है कि डिबेट उत्पन्न करने के लिए ड्रोन फ़ाइल को बदलने के लिए पीआर कौन भेज सकता है? @tboerger @bkcsoft @appleboy

@jhasse की तुलना में हम ओपन बिल्ड सर्विस का भी उपयोग कर सकते हैं। मुझे विश्वास नहीं है कि ये उपकरण सबसे अच्छे चयन हैं।

मैं आरपीएम के लिए और बहस के लिए एक ड्रोन प्लगइन पसंद करूंगा और रेपो को स्वयं या बिंट्रे/पैकेजक्लाउड पर होस्ट करूंगा

@tboerger - बस उत्सुक है कि क्या आप मुझे ड्रोन सामान पर एक स्टैब लेना चाहेंगे? कारण मैं पूछता हूं क्योंकि मैं अपने रेपो को ट्रैविसी में जोड़ने के बारे में सोच रहा था। मैं पूरी तरह से समझता हूं कि क्या आप लोग स्वयं निहित निर्माण सेवा पसंद करेंगे। :)

यदि आप चाहते हैं कि मैं ड्रोन की जांच करूं तो क्या आप इस बारे में कोई दस्तावेज साझा कर पाएंगे कि आपकी टीम इसका उपयोग कैसे कर रही है? मैं मानकों पर बड़ा हूं और अगर मेरे पास भी नहीं है तो पहिया को फिर से बनाना पसंद नहीं है।

वर्तमान में हम ड्रोन-प्लगइन्स जीथब ऑर्ग से ड्रोन योगदानकर्ताओं द्वारा बनाए गए ज्यादातर प्लगइन्स का उपयोग कर रहे हैं, @thomasf ने डेबियन आधारित पैकेजिंग के लिए ड्रोन-डेब का निर्माण शुरू किया है और मैं ड्रोन-प्लगइन्स संगठन के भीतर ड्रोन-आरपीएम प्लगइन शुरू करना चाहता हूं।

आप हमारे .drone.yml को प्रोजेक्ट रूट के भीतर देख सकते हैं, हम अपने ड्रोन इंस्टेंस को ड्रोन.gita.io पर होस्ट कर रहे हैं

ठंडा। एक बार जब मैं इस सिस्टमड समस्या को ठीक कर देता हूं तो मैं आपकी सिफारिश के अनुसार एक नज़र डालूंगा। धन्यवाद दोस्त!

FYI करें - सिस्टमड समस्या हल हो गई है और RPM अच्छे कार्य क्रम में होने चाहिए। अभी भी ड्रोन सामान को देखने की जरूरत है।

लिनक्स के तहत "पैकेज" के माध्यम से इंस्टॉलेशन का एक सरल साधन प्रदान करने के लिए बस एक और विचार में फेंकना: http://linuxbrew.sh।

नमस्ते, डिबेट पैकेज के बारे में कोई खबर? मैं वास्तव में एक गीता डिबेट पैकेज लेना पसंद करूंगा;)
वास्तव में मुझे उबंटू 16.04 और उबंटू 18.04 के लिए उनकी आवश्यकता होगी, बस अधिक सटीक होने के लिए ...

मैं डेबियन पैकेज बनाने और इसे उपलब्ध कराने के लिए भी तैयार हूं यदि यह कदम पहले नहीं किया गया है, तो बस मुझे बताएं;)

इस समस्या को स्वचालित रूप से पुराने के रूप में चिह्नित कर दिया गया है क्योंकि इसमें हाल की गतिविधि नहीं है। यदि अगले 2 सप्ताह के दौरान कोई और गतिविधि नहीं होती है तो इसे बंद कर दिया जाएगा। आपके योगदानों के लिए धन्यवाद।

आपके योगदान के लिए धन्यवाद स्टेलबोट।

मैं अभी भी डेबियन पैकेजिंग के लिए अपने github.com/xor-gate/debpkg गो पैकेज का प्रचार कर रहा हूं।

@ xor-gate क्या आप contrib पर अपनी लाइब्रेरी के लिए एक कॉन्फ़िग फ़ाइल जोड़ने के लिए एक पीआर भेज सकते हैं? हो सकता है कि हम इसे ड्रोन प्लगइन पर जारी कर सकें।

इस समस्या को स्वचालित रूप से पुराने के रूप में चिह्नित कर दिया गया है क्योंकि इसमें हाल की गतिविधि नहीं है। यदि अगले 2 सप्ताह के दौरान कोई और गतिविधि नहीं होती है तो इसे बंद कर दिया जाएगा। आपके योगदानों के लिए धन्यवाद।

कृपया इसकी मांग के रूप में विचार करें ...

समाधान के अभाव में ही बासी है।

मुझे नहीं लगता कि गीता को पैक करके रखने के लिए किसी एक व्यक्ति के पास पर्याप्त ऊर्जा है
डेबियन मुख्य, विशिष्ट गोलंग के साथ बहुत अधिक निर्भरताएं हैं
पारिस्थितिकी तंत्र की समस्याएं [1]। मैंने इसे बनाने की कोशिश में> 30 घंटे/सप्ताह से अधिक समय बिताया
होना; जब मैंने हार मान ली, तो मुझे काम करने में तीन महीने से भी कम समय लगा
में परिवर्तन को तोड़ने के कारण संग्रह से खींचे जाने के लिए डेबियन में धकेल दिया गया
निर्भरता।

मैं किसी को इसे गैर-मुक्त बनाए रखने में मदद कर सकता हूं (या यदि कोई मर्दवादी हो तो मुख्य)
टीम खुद को प्रस्तुत करती है), लेकिन इसे कमी के बारे में चेतावनी के साथ आना होगा
स्थिरता की, कई कारणों से।

[1]

• कुछ पुस्तकालय मर चुके हैं, उनके खिलाफ सुरक्षा बग के साथ
• रखरखाव के विभिन्न स्तरों के साथ बहुत सारे कामों को फोर्क किया गया है (ज्यादातर
  पैच और भूल जाओ)
• नए पुस्तकालयों को मनमाने ढंग से जोड़ा जाता है, अक्सर बहुत कम या बिना किसी समीक्षा के
• 'गो वेंडर' (कर्ल | ​​सूडो -)
• >200 गोलांग डिपो शायद ही कभी रिलीज़ प्रदान करते हैं (ऐप्लिकेशन हमेशा जारी रहने की अपेक्षा करते हैं
  नवीनतम गिट खींचें, जिसमें अतिरिक्त डीपीएस libs जोड़ा गया है)

इसके अतिरिक्त-

• ऐसा प्रतीत होता है कि सुरक्षा अद्यतनों के समन्वय के लिए कोई विधि नहीं है
  मानसिकता है कि अपडेट करने से आप सुरक्षित रहते हैं... यह इसके विपरीत करता है)
• >2000 गोलांग लिबस >2,000 जेएस लिबस की तुलना में फीका पड़ जाता है
• कानूनी रूप से क्या शामिल किया जा सकता है, इस बारे में चिंता का एक भयानक अभाव है
  खुला स्रोत सॉफ्टवेयर
• इन मुद्दों को ठीक करने के प्रयासों को महत्वपूर्ण प्रतिरोध का सामना करना पड़ा है

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

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

>

@MTecknology इस समस्या को हल करने के लिए एक पीआर है। https://github.com/go-gita/gitea/pull/6671 देखें ।

यह मेरे द्वारा उल्लिखित किसी भी समस्या का समाधान नहीं करता है, यह उन सभी को एक सुविधाजनक पैकेज में पेश करता है जो अभी भी डेबियन संग्रह के लिए अनुपयुक्त है।

और स्वचालित रूप से निर्मित डेबियन पैकेज प्रदान करने के लिए एक पीपीए (जिसे हम होस्ट करेंगे) प्रदान करने के बारे में क्या?

सोचा होगा कि जेएस पुस्तकालयों को गीता के साथ ही बंडल किया जाएगा - मैंने हमेशा उपयुक्त के माध्यम से उपलब्ध तथाकथित जावास्क्रिप्ट पुस्तकालयों के संस्करणों से परहेज किया है, क्योंकि आप गारंटी नहीं दे सकते कि कौन सा संस्करण है।

जहां तक ​​गो लाइब्रेरी की बात है, मैंने सोचा कि गीता सिर्फ एक बाइनरी जारी करती है? कम से कम मैं तो यही इस्तेमाल कर रहा हूं। क्या एक साधारण उपयुक्त भंडार नहीं बनाया जा सकता है जिसमें एक पैकेज हो जिसमें वह एकल बाइनरी हो?

अस्वीकरण: मैं एक डेबियन अनुचर _not_ हूं, और चीजों को .deb फाइलों में पैक करने का अनुभव सीमित है। मेरा अनुभव fpm . तक चलता है

@MTecknology आपने बहुत बड़ी मात्रा में काम किया है, लेकिन दुर्भाग्य से मुझे ऐसा लगता है कि यह डेबियन के लिए gita पैकेज करने के लिए जरूरी नहीं है। सुरक्षा या बग फिक्स के साथ पुराने संस्करणों का समर्थन करने के लिए परियोजना में कोई लक्ष्य नहीं है जो डेबियन रिलीज चक्र से मेल खाएगा। और जैसा कि आपने उल्लेख किया है, निर्भरता की मात्रा अप्रबंधनीय है। गो कहावत "थोड़ी निर्भरता से थोड़ी नकल बेहतर है।" उपेक्षा की गई है। लेकिन यह काफी समझ में आता है, क्योंकि यह निर्भरता को अद्यतित रखने या कॉपी किए गए कोड को केवल आवश्यक सामान और फिर बैकपोर्टिंग फ़िक्सेस को शामिल करने जैसे सामानों के लिए छोटे संसाधनों के साथ एक स्वयंसेवी प्रयास है। और जेएस/एनपीएम निर्भरता की दुनिया और भी बदतर है। मेरा मानना ​​​​है कि गिटिया जैसे सॉफ़्टवेयर को डॉकटर छवियों के रूप में बेहतर ढंग से पेश किया जाता है जो कई लिनक्स वितरण पर काम करते हैं। उम्मीद है कि डॉकर छवियों को बंद कर दिया गया है, क्योंकि कोड में अभी भी निर्भरता और सुरक्षा सुधारों के मुद्दे हैं जिनका आपने उल्लेख किया है।

एक यम रेपो प्रदान करें और उपयुक्त स्रोत एक और होगा जिसमें इंस्टॉलेशन शेल स्क्रिप्ट एक और विकल्प होगा।

बेशक डेबियन या ubuntu के आधिकारिक रिपॉजिटरी में गीता होना अच्छा होगा, लेकिन जैसा कि पहले ही ऊपर कहा जा चुका है कि इसके परिणामस्वरूप बहुत काम होता है।

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

संकुल स्वयं एफपीएम के माध्यम से बनाया जा सकता है, या कोई ड्रोन प्लगइन का योगदान देता है जो ड्रोन-प्लगइन्स संगठन में भी उतर सकता है यदि यह जाने में लिखा गया है और कुछ मानकों को मिला है। यहां तक ​​​​कि एक गो लाइब्रेरी भी है जो बहुत सारी एफपीएम सुविधाओं को लागू करती है।

वितरण के लिए औपचारिक रूप से पैकेजिंग के संदर्भ में, हालांकि यह एक दीर्घकालिक लक्ष्य हो सकता है और शायद होना चाहिए, मुझे नहीं लगता कि हमें वर्तमान में ऐसा करना चाहिए। हमारा कोडबेस अभी भी तेजी से बदल रहा है और मुझे लगता है कि वर्तमान में हम बहुत पुराने संस्करणों को बनाए रखने के लिए प्रतिबद्ध नहीं हो सकते हैं जो इन वितरणों के साथ औपचारिक रूप से पैक किए जाएंगे।

मैं बाहरी निर्भरताओं की संख्या के बारे में भी चिंतित हूं जो हमारे पास हैं - हमें निश्चित रूप से इस बारे में सोचना चाहिए कि क्या हमें इन्हें कठोर निर्भरताओं (जैसे भव्य, बोल्टडब) के रूप में चाहिए और क्या हमारी कुछ छोटी निर्भरताओं को फोर्क या फिर से लिखने से लाभ हो सकता है। (मैकरॉन सत्र और गो-इनी दोनों समस्याग्रस्त इम्हो हैं।)

गो प्लगइन्स को वास्तविकता बनाने के लिए हमें अपनी आंतरिक संरचना को फिर से तैयार करने की भी आवश्यकता है। मुझे लगता है कि यह हमें एक दुबला कोर-गीता बनाने की अनुमति देगा जिसे अन्य सभी निर्भरताओं को लाए बिना पैक किया जा सकता है।

किसी भी वितरण पर एक PITA गो परियोजनाओं की उचित पैकेजिंग है। इसलिए हमें केवल बाइनरी का निर्माण करना चाहिए और सरल पैकेज प्रदान करना चाहिए जो प्रत्येक निर्भरता को एक अलग पैकेज के रूप में पैकेज करने के लिए वितरण की सर्वोत्तम प्रथाओं को अनदेखा करते हैं।

डेबियन अनुरक्षक के रूप में बोलते हुए, डेबियन में गीता को पैकेज के रूप में रखना बहुत अच्छा होगा। लेकिन इसके साथ तकनीकी (और शायद लाइसेंस) मुद्दे हैं, इसलिए यह इस मुद्दे के दायरे से बाहर है।

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

सेंटोस आरपीएमएस: https://cbs.centos.org/koji/buildinfo?buildID=25894

एक आरपीएम को बार-बार अपडेट किए जाने वाले डीएनएफ/यम रेपो में प्राप्त करना बहुत अच्छा होगा ताकि आरपीएम डिस्ट्रो उपयोगकर्ता आसानी से सुरक्षा अपडेट आदि के साथ गीता के लिए अप-टू-डेट रह सकें।

@waja आपके CentOS पैकेज का कोई भी परिवर्तन फेडोरा के लिए अद्यतन किया जा रहा है और संभवतः EPEL में जोड़ा जा रहा है यदि यह परीक्षण और स्थिर है?

इस पर कोई भी समाचार? एक महीने पहले #6671 में @techknowlogic ने कहा था कि ड्रोन का इस्तेमाल आरपीएम और डीबीएस के स्वचालित बिल्ड के लिए किया जा सकता है। क्या किसी ने इसे सक्षम करने के लिए एक क्षण खोजने का प्रबंधन किया? यदि हां, तो क्या आप कृपया दस्तावेज़ीकरण अपडेट कर सकते हैं?

@ जेनहाउस मैं इसे फेडोरा के लिए पैक करने की कोशिश कर रहा हूं लेकिन गो को ठीक से पैक करने का दर्द है। ऊपर लिंक किया गया CentOS संस्करण वास्तव में मेरे लिए ठीक से नहीं बना था और मैंने इसके साथ होने वाले कुछ बदलावों पर ध्यान दिया।

मुझे अभी भी उचित आधिकारिक बिल्ड में दिलचस्पी है, हालांकि यह सुनिश्चित करता है कि पैकेज बेहतर तरीके से बनाए रखा जाए।

@waja आधिकारिक डिबेन रेपो में एक परियोजना प्राप्त करने के बारे में बहुत कुछ नहीं जानता है, लेकिन अल्पाइन-लिनक्स के पास पहले से ही एक कार्यशील पैकेज है: स्रोत

हमें आधिकारिक डेबियन रिपॉजिटरी में गीता नहीं मिलेगी, यह वास्तव में बहुत बड़ा प्रयास है जो पहले ही विफल हो चुका है।

पीपीए को बनाए रखना कितना कठिन है?

विशेष रूप से कठिन नहीं, @ 6543। वास्तव में, यहाँ मेरा अपना उपयुक्त भंडार है: https://apt.starbeamrainbowlabs.com/

मैं इसे प्रबंधित करने के लिए जिस कोड का उपयोग करता हूं वह यहां पाया जा सकता है: https://git.starbeamrainbowlabs.com/sbrl/aptosaurus

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

पैकेज का निर्माण ड्रोन द्वारा किया जाना चाहिए, और इसे बस बिंट्रे पर अपलोड किया जाना चाहिए;)

@tboerger मैं डिबेट बिल्ड स्क्रिप्ट के साथ एक मसौदा पीआर बनाने की कोशिश करूँगा ...
और हमारे पास dl.gitea.io है, क्या वहां भी डिबेट अपलोड करना उचित है (और शायद रिलीज पर अटैचमेंट के रूप में)

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

बिना किसी भंडार के सिर्फ एक डिबेट या आरपीएम फ़ाइल अपलोड करना आईएमएचओ बहुत बेकार है।

यह पूरी तरह से बकवास है!

हम deb और rpm फाइल बनाने के लिए nfpm का भी उपयोग कर सकते हैं

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

यहाँ एक ड्रोन प्लगइन है जिसे मैंने nfpm के लिए बनाया है: https://github.com/techknowlogic/drone-nfpm

यदि आप FHS सिस्टम के लिए पैकेज बनाते हैं तो याद रखें कि या तो contrib में शैडोइंग स्क्रिप्ट का उपयोग करें या LDFLAGS सेट के साथ सही ढंग से निर्माण करें।

हाय सब, मेरे पास अपने स्वयं के एपीटी पैकेज भंडार हैं, मैं इसमें गीता जोड़ सकता हूं।
पहले से शामिल परियोजना देखें: https://packages.azlux.fr/
अब यह चल रहा है, कोई भी .deb जो आप चाहते हैं उसे जोड़ना आसान है (मैं इसे बना भी सकता हूँ)

अज़्लक्स

@azlux यह सब भरोसे के लिए आता है। आप शायद एक अच्छे आदमी हैं, लेकिन मैं इसे कुछ ज्ञात ऑटोमेशन सेवा से स्थापित करना चाहूंगा, जहां कुछ निजी रेपो से प्राप्त करने के बजाय, गीता देव टीम द्वारा स्क्रिप्ट का निर्माण किया जाता है। मेरे अपने पैकेज भी बनाए गए हैं, लेकिन आदर्श रूप से इसे गीता टीम द्वारा प्रबंधित किया जाएगा।

हो ठीक है
जानकारी के लिए धन्यवाद @Janhouse
मैंने अपना रेपो रेप्रेप्रो के साथ सेटअप किया है, यदि आपको आवश्यकता हो तो मैं मदद कर सकता हूं।

अज़ू

@Janhouse एक गहरी सोच के बाद, उपयुक्त रेपो हमें यह सत्यापित करने की अनुमति देता है कि इस बीच स्रोतों को संशोधित नहीं किया गया है। आदर्श रूप से, यह बेहतर है कि गीता अपने स्वयं के रेपो को बनाए रखे, लेकिन वे अन्य रेपो को "अनौपचारिक भंडार" के रूप में भी रख सकते हैं।
बहुत से प्रोजेक्ट में इससे कोई समस्या नहीं है। ऐसे में लोगों ने चेताया।

मुझे पता है कि मैंने यह पहले भी कहा है लेकिन ...

यदि आप देब पैकेज प्रदान कर रहे हैं, तो आपको संभवतः गीता का निर्माण करना चाहिए ताकि वह यहां वर्णित एलडीएफएलएजीएस को सेट करके एफएचएस का पालन करे:

https://docs.gita.io/en-us/install-from-source/#changeing -the-default-custompath-customconf-and-appworkpath

यहां वही - मेरे पास एक व्यक्तिगत उपयुक्त रेपो है जिसे मैं होस्ट कर सकता हूं

मैं यह भी देखना चाहूंगा कि gita FHS @zeripath का अनुसरण करता है, यह मूर्खतापूर्ण है कि उन्हें ऐसा करने के लिए एक रैपर शेल स्क्रिप्ट की भी आवश्यकता है।

इस बीच आरपीएम पर कोई खबर? मुझे डीईबी के बारे में बहुत सारी चर्चाएँ दिखाई देती हैं लेकिन कई उद्यम सेंटोस का उपयोग कर रहे होंगे जो डीईबी पैकेज का उपयोग नहीं करते हैं। ऐसा लगता है कि बीएसडी के अपने पैकेज (पैच के साथ) हैं, लेकिन उनकी प्रक्रियाएं थोड़ी अलग हैं।

@evitalis यदि आप इसे उपयुक्त LDFLAGS के साथ बनाते हैं तो आपको स्क्रिप्ट की आवश्यकता नहीं है।

मुझे पता है, मैं उनकी जरूरत की बात कर रहा था यहां तक ​​कि यह भी।

बस यही सोच रहा है। FHS पथ v2 के लिए डिफ़ॉल्ट होना चाहिए क्योंकि यह एक आवश्यक ब्रेकिंग परिवर्तन होगा।

मुझे लगता है कि हमें इसे थोड़ा कम करने की जरूरत है। वर्तमान में चार प्रकार के निर्माण हैं:

• विकास बनाता है - आप स्रोत डाउनलोड करते हैं और आप make . के साथ निर्माण करते हैं
• व्यक्तिगत बिल्ड - आप स्रोत डाउनलोड करते हैं और आप मेक के साथ निर्माण करते हैं लेकिन यह एक चालू सर्वर चाहते हैं
• रिलीज़ बिल्ड - हम मेक रिलीज़ के साथ निर्माण करते हैं और gitea.io और GH पर चिपके रहते हैं
• डोकर बनाता है

डिफ़ॉल्ट रूप से FHS उनमें से 2 तक के लिए समझ में आता है: रिलीज़ और संभवतः व्यक्तिगत - लेकिन वर्तमान में आप यह नहीं बता सकते हैं कि कोई व्यक्तिगत निर्माण एक विकास निर्माण है या इसके विपरीत। विकास के भवनों को तोड़ना एक बहुत ही बुरा विचार होगा।

डॉकर में इसके डिफॉल्ट्स भी एम्बेडेड होने चाहिए - हमारे द्वारा बनाए गए डॉकटर बिल्ड पर डिफ़ॉल्ट रूप से "-c" की आवश्यकता होना बेमानी है।

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

जब मैंने पहली बार एलडीएफएलजीएस विकल्प का काम किया तो मैंने प्रस्तावित किया:

• एम्बेडेड FHS पथों के साथ एक अलग रिलीज़ करें
• डॉकर को एम्बेडेड डॉकटर के लिए डिफ़ॉल्ट पथ बनाएं - जो डॉक कमांड लाइन पर चलने वाले गिटिया के साथ कुछ अन्य अजीब मुद्दों को हल करता है।
• FHS बिल्ड के लिए एक मेक एंडपॉइंट जोड़ें/एक्सपोज़ करें जो फ़्लैग को ठीक से सेट करता है <- पैकेज बिल्डरों को इसका उपयोग करना चाहिए ...

ये गैर-ब्रेकिंग परिवर्तन हैं जिनके लिए 2.0 की प्रतीक्षा करने की आवश्यकता नहीं होगी - हम केवल एक नया डाउनलोड विकल्प जोड़ रहे हैं।

एक विकल्प यह है कि एक कॉन्फ़िगर स्क्रिप्ट जोड़ें और एंडपॉइंट स्थापित करें - तब यह लोगों के लिए "सामान्य" दिखाई देगा:

# get source by whatever means necessary
cd gitea
./configure
make
sudo make install

यदि आप किसी कस्टम पथ के लिए फ़्लैग प्रदान नहीं करते हैं, तो कॉन्फ़िगरेशन के लिए पूर्वनिर्धारित पथों में खोजना बिल्कुल सामान्य है। यह एक उदाहरण के रूप में कई मानक पथों को परिभाषित करने के लिए पहले से ही https://github.com/spf13/viper का हिस्सा है। गीता का वर्तमान गड़बड़ व्यवहार पूरी तरह से असामान्य है।

शायद रिलीज को रेपो में बनाने के लायक होगा, पहले एक अच्छा पहला कदम होगा?

@sbrl पहले से ही मेरे रेपो पर किया गया है, बिल्ड स्क्रिप्ट यहां स्टोर है: https://github.com/azlux/dpkg-deb
जैसा कि आपने कहा, यह सीधे रिलीज बिल्ड का उपयोग करता है।

@zeripath मुझे लगता है कि आप इसे अपने उत्तर के आधार पर और अधिक जटिल बना रहे हैं, लेकिन मैं इसे गलत व्याख्या कर सकता हूं। अगर लोग git clone चला रहे हैं और चीजें खुद बना रहे हैं तो उन्हें पता होना चाहिए कि समस्याएं हो सकती हैं। कई परियोजनाओं के लिए या तो master शाखा से निर्माण करना या किसी रिलीज़ का उपयोग करना स्थिर माना जाता है, और कुछ भी नहीं है और किसी भी समय टूट सकता है।

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

इन सब बातों के साथ-साथ मुझे अभी भी कम से कम आधिकारिक RPM देखने में दिलचस्पी है। मैं डेबियन या उबंटू का उपयोग नहीं करता लेकिन मुझे यकीन है कि एक आधिकारिक डीईबी का भी स्वागत होगा। इस धागे में सभी को धन्यवाद, जो अंतरिम में पैकेजिंग पर अपना सर्वश्रेष्ठ प्रदर्शन कर रहे हैं।