मुझे Linux के लिए अपना सॉफ़्टवेयर पैकेज करना नापसंद है
स्वतंत्र डेवलपर्स एक बिखरे हुए ecosystem में, जहाँ distros, package managers, और runtime assumptions अलग-अलग हैं, Linux applications वितरित करने में संघर्ष कर रहे हैं। कई लोगों का तर्क है कि एक solo maintainer के लिए हर format को support करना अवास्तविक है, और वे या तो simple static binaries ship करने या packaging को distro maintainers पर छोड़ देने की वकालत करते हैं, भले ही इससे reach और auto-update की सुविधा सीमित हो जाए। अन्य लोग self-updating binaries, container-style approaches (Flatpak, Docker, Nix), या external tools जैसे workaround तलाशते हैं, लेकिन सार्वभौमिक, कम-घर्षण समाधान पर कोई सहमति नहीं है.
समस्या का दायरा
- थ्रेड इस बात से सहमत है कि Linux पैकेजिंग बिखरी हुई है: कई डिस्ट्रीब्यूशन्स, कई पैकेज मैनेजर्स, और साथ में नई परतें (Flatpak, Snap, AppImage, Nix, Homebrew, आदि)।
- अकेले मेंटेनर पाते हैं कि सभी डिस्ट्रीब्यूशन्स को कवर करना और अपडेट्स को जारी रखना मुश्किल है, खासकर गैर-तुच्छ निर्भरताओं के लिए (जैसे Rust में कई crates, Python, आदि)।
किसे पैकेज करना चाहिए?
- एक पक्ष: डेवलपर को मुख्यतः source, सरल build निर्देश, और शायद एक tarball या static binary ship करना चाहिए; distro maintainers से अपेक्षा है कि वे distro-specific packaging करें।
- विरोधी तर्क: distros पर निर्भर रहने का मतलब है कि अगर कोई maintainer आगे न आए तो सॉफ़्टवेयर प्रभावी रूप से उपलब्ध ही नहीं होगा; users के पास package या build करने के लिए skill/time नहीं हो सकता।
- कुछ लोग कहते हैं कि यह “दशकों से काम करता आया है”; अन्य लोग नोट करते हैं कि यह software को बाहर कर देता है और गैर-विशेषज्ञ users को निराश करता है।
Static और Self-Updating Binaries
- कई लोग एक single static (या अधिकांशतः static) binary के साथ built-in self-update को सबसे व्यावहारिक cross-distro समाधान मानते हैं, खासकर CLIs/TUIs के लिए।
- उद्धृत उदाहरण: अन्य Rust tools, Firefox का अपना updater, विभिन्न Go/Rust utilities।
- चिंताएँ: performance (musl बनाम glibc), self-modifying executables की security, और कुछ Linux circles से सामाजिक विरोध।
वैकल्पिक वितरण चैनल
- Container-जैसे समाधान: Docker/Podman/systemd-nspawn या पूरा userspace/squashfs ship करना विश्वसनीय माना जाता है लेकिन भारी है, खासकर embedded या कम-storage systems के लिए।
- Steam/Proton: GUI apps के लिए लंबे समय तक स्थिर runtimes पाने का एक तरीका सुझाया गया, लेकिन non-games के लिए UX अजीब है और यह एक proprietary platform पर निर्भर करता है।
- Flatpak: GUI apps के लिए अच्छी तरह काम करता है, लेकिन CLI/TUI support और permission model को अटपटा माना जाता है।
- Nix, OBS, PPAs, personal Debian repos, Linux पर Homebrew को उपयोगी बताया गया, लेकिन हर एक अपनी जटिलता और learning curve जोड़ता है।
Build-from-Source और Tooling
- पारंपरिक
./configure && make && make install(याcargo install) को कुछ लोग अभी भी व्यावहारिक मानते हैं; अन्य कहते हैं कि dependency mismatches के कारण यह अक्सर विफल हो जाता है। - कई टिप्पणियाँ modern tooling और CI (Nix, GitHub Actions, Open Build Service, checkinstall) का उपयोग करने, और packaging metadata auto-generate करने के लिए LLMs तक सुझाती हैं।
Windows/macOS तुलना
- कई पोस्टर दावा करते हैं कि व्यवहार में Windows packaging आसान है: app के साथ सभी DLLs bundle करें और installers ship करें।
- macOS और mobile platforms की अपनी bureaucracy (certs, stores) है, लेकिन कम से कम वे Linux ecosystem के विपरीत, अपेक्षाकृत एकीकृत रास्ता प्रस्तुत करते हैं।